Re: killing perl2host

[Thomas Munro]

On Sun, Feb 20, 2022 at 10:51 AM Andrew Dunstan  wrote:
> On 2/19/22 16:34, Andres Freund wrote:
> >> The first
> >> removes perl2host completely and adjusts  all the places that use it.
> >> The second removes almost all the remaining msys special processing in
> >> TAP tests.

Very nice improvement.  Thanks for sorting this out.  I didn't enjoy
playing "Wordle" with the build farm.

Re: killing perl2host

[Andres Freund]

On 2022-02-19 16:51:18 -0500, Andrew Dunstan wrote:
> I will backpatch it. That'll be a bit of fun given how much the TAP
> tests change, but I think it's worth it.

Agreed. And thanks.

Re: killing perl2host

[Andrew Dunstan]

On 2/19/22 16:34, Andres Freund wrote:
> Hi,
>
> On 2022-02-19 13:04:05 -0500, Andrew Dunstan wrote:
>> OK, nothing broke, so here are two more invasive patches.
> Great!
>
>
>> The first
>> removes perl2host completely and adjusts  all the places that use it.
>> The second removes almost all the remaining msys special processing in
>> TAP tests.
> Hm. Do we have to worry about backpatched bugfixes breaking in the
> backbranches? Or are you planning to backpatch this stuff?
>


I will backpatch it. That'll be a bit of fun given how much the TAP
tests change, but I think it's worth it.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andres Freund]

Hi,

On 2022-02-19 13:04:05 -0500, Andrew Dunstan wrote:
> OK, nothing broke, so here are two more invasive patches.

Great!


> The first
> removes perl2host completely and adjusts  all the places that use it.
> The second removes almost all the remaining msys special processing in
> TAP tests.

Hm. Do we have to worry about backpatched bugfixes breaking in the
backbranches? Or are you planning to backpatch this stuff?

Greetings,

Andres Freund

Re: killing perl2host

[Andrew Dunstan]

On 2/19/22 13:04, Andrew Dunstan wrote:
> On 2/16/22 15:46, Andrew Dunstan wrote:
>> Largely following a recipe from Andres, I have migrated buildfarm
>> animals fairywren and jacana to a setup that shouldn't need (and in fact
>> won't be able to use) PostgreSQL::Test:Utils::perl2host(). AFAICT these
>> two are the only buildfarm animals that run TAP tests under msys.
> [...]
>
>
>> I suggest that we apply this patch:
>>
>>
> [...]
>> and if nothing breaks in a few days I will set about a more thorough
>> removal of perl2host() and adjusting everywhere it's called, and we can
>> forget that the whole sorry mess ever happened :-) I know a number of
>> people who will be overjoyed.
>>
>>
>
> OK, nothing broke, so here are two more invasive patches. The first
> removes perl2host completely and adjusts  all the places that use it.
> The second removes almost all the remaining msys special processing in
> TAP tests.
>
>
> I have tested these and they appear to work fine.
>
>

It turns out we can also remove the skip code in
src/bin/pg_dump/t/010_dump_connstr.pl


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andrew Dunstan]

On 2/16/22 15:46, Andrew Dunstan wrote:
> Largely following a recipe from Andres, I have migrated buildfarm
> animals fairywren and jacana to a setup that shouldn't need (and in fact
> won't be able to use) PostgreSQL::Test:Utils::perl2host(). AFAICT these
> two are the only buildfarm animals that run TAP tests under msys.

[...]


> I suggest that we apply this patch:
>
>
[...]
>
> and if nothing breaks in a few days I will set about a more thorough
> removal of perl2host() and adjusting everywhere it's called, and we can
> forget that the whole sorry mess ever happened :-) I know a number of
> people who will be overjoyed.
>
>


OK, nothing broke, so here are two more invasive patches. The first
removes perl2host completely and adjusts  all the places that use it.
The second removes almost all the remaining msys special processing in
TAP tests.


I have tested these and they appear to work fine.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From 50d09dab80bb14ec14f36e95037a72cc075957fe Mon Sep 17 00:00:00 2001
From: Andrew Dunstan 
Date: Fri, 18 Feb 2022 17:00:03 -0500
Subject: [PATCH 1/2] remove perl2host completely

---
 src/bin/pg_basebackup/t/010_pg_basebackup.pl  | 18 +++---
 src/bin/pg_checksums/t/002_actions.pl |  1 -
 src/bin/pg_verifybackup/t/003_corruption.pl   |  4 +-
 src/bin/pg_verifybackup/t/008_untar.pl|  3 +-
 src/bin/pgbench/t/001_pgbench_with_server.pl  |  4 +-
 src/bin/scripts/t/090_reindexdb.pl|  1 -
 .../modules/test_misc/t/002_tablespace.pl |  4 +-
 src/test/perl/PostgreSQL/Test/Cluster.pm  |  4 +-
 src/test/perl/PostgreSQL/Test/Utils.pm| 58 ---
 src/test/recovery/t/014_unlogged_reinit.pl|  4 +-
 src/test/recovery/t/017_shm.pl|  2 +-
 src/test/recovery/t/018_wal_optimize.pl   |  2 -
 .../recovery/t/025_stuck_on_old_timeline.pl   |  2 +-
 src/test/recovery/t/027_stream_regress.pl |  4 +-
 src/test/ssl/t/001_ssltests.pl|  4 +-
 src/test/ssl/t/002_scram.pl   |  2 +-
 src/test/ssl/t/003_sslinfo.pl |  2 +-
 17 files changed, 25 insertions(+), 94 deletions(-)

diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
index 8c70e5b32b..75d6810d3e 100644
--- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
+++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
@@ -261,13 +261,11 @@ $node->start;
 # for the tablespace directories, which hopefully won't run afoul of
 # the 99 character length limit.
 my $sys_tempdir = PostgreSQL::Test::Utils::tempdir_short;
-my $real_sys_tempdir = PostgreSQL::Test::Utils::perl2host($sys_tempdir) . "/tempdir";
-my $shorter_tempdir =  $sys_tempdir . "/tempdir";
-dir_symlink "$tempdir", $shorter_tempdir;
+my $real_sys_tempdir = "$sys_tempdir/tempdir";
+dir_symlink "$tempdir", $real_sys_tempdir;
 
 mkdir "$tempdir/tblspc1";
 my $realTsDir= "$real_sys_tempdir/tblspc1";
-my $real_tempdir = PostgreSQL::Test::Utils::perl2host($tempdir);
 $node->safe_psql('postgres',
 	"CREATE TABLESPACE tblspc1 LOCATION '$realTsDir';");
 $node->safe_psql('postgres',
@@ -346,7 +344,7 @@ my $tblSpc1Id = basename(
 foreach my $filename (@tempRelationFiles)
 {
 	append_to_file(
-		"$shorter_tempdir/tblspc1/$tblSpc1Id/$postgresOid/$filename",
+		"$real_sys_tempdir/tblspc1/$tblSpc1Id/$postgresOid/$filename",
 		'TEMP_RELATION');
 }
 
@@ -358,7 +356,7 @@ $node->command_ok(
 	[
 		@pg_basebackup_defs, '-D',
 		"$tempdir/backup1",  '-Fp',
-		"-T$realTsDir=$real_tempdir/tbackup/tblspc1",
+		"-T$realTsDir=$tempdir/tbackup/tblspc1",
 	],
 	'plain format with tablespaces succeeds with tablespace mapping');
 ok(-d "$tempdir/tbackup/tblspc1", 'tablespace was relocated');
@@ -406,7 +404,7 @@ foreach my $filename (@tempRelationFiles)
 
 	# Also remove temp relation files or tablespace drop will fail.
 	my $filepath =
-	  "$shorter_tempdir/tblspc1/$tblSpc1Id/$postgresOid/$filename";
+	  "$real_sys_tempdir/tblspc1/$tblSpc1Id/$postgresOid/$filename";
 
 	unlink($filepath)
 	  or BAIL_OUT("unable to unlink $filepath");
@@ -428,7 +426,7 @@ $node->command_ok(
 	[
 		@pg_basebackup_defs, '-D',
 		"$tempdir/backup3",  '-Fp',
-		"-T$realTsDir=$real_tempdir/tbackup/tbl\\=spc2",
+		"-T$realTsDir=$tempdir/tbackup/tbl\\=spc2",
 	],
 	'mapping tablespace with = sign in path');
 ok(-d "$tempdir/tbackup/tbl=spc2", 'tablespace with = sign was relocated');
@@ -517,7 +515,7 @@ $node->command_ok(
 	[ @pg_basebackup_defs, '--target', 'blackhole', '-X', 'none' ],
 	'backup target blackhole');
 $node->command_ok(
-	[ @pg_basebackup_defs, '--target', "server:$real_tempdir/backuponserver", '-X', 'none' ],
+	[ @pg_basebackup_defs, '--target', "server:$tempdir/backuponserver", '-X', 'none' ],
 	'backup target server');
 ok(-f "$tempdir/backuponserver/base.tar", 'backup tar was created');
 rmtree("$tempdir/backuponserver");
@@ -526,7 +524,7 @@ $node->command_ok(
 	[qw(createuser --replication --role=pg_write_server_files 

Re: killing perl2host

[Andrew Dunstan]

On 2/18/22 17:34, Andrew Dunstan wrote:
> On 2/17/22 12:12, Andres Freund wrote:
>> Hi,
>>
>> On 2022-02-17 09:20:56 -0500, Andrew Dunstan wrote:
>>> I don't think we have or have ever had a buildfarm animal targeting
>>> msys. In general I think of msys as a build environment to create native
>>> binaries. But if we want to support targeting msys we should have an
>>> animal doing that.
>> It's pretty much cygwin. Wouldn't hurt to have a dedicated animal though, I
>> agree. We do have a dedicated path for it in configure.ac:
>>
>> case $host_os in
>> ...
>>   cygwin*|msys*) template=cygwin ;;
>
>
> FYI I tested it while in wait mode for something else, and it fell over
> at the first hurdle:
>
>
> running bootstrap script ... 2022-02-18 22:25:45.119 UTC [34860] FATAL: 
> could not create shared memory segment: Function not implemented
> 2022-02-18 22:25:45.119 UTC [34860] DETAIL:  Failed system call was
> shmget(key=1407374884304065, size=56, 03600).
> child process exited with exit code 1
>
>
> I'm not intending to put any more effort into supporting it.


See also

where Peter says:


MSYS2 doesn't ship with cygserver AFAICT, so you can't run a
PostgreSQL server, but everything else should work.


which explains this perfectly. If we can't run a server then any sort of
buildfarm/CI support seems moot.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andrew Dunstan]

On 2/17/22 12:12, Andres Freund wrote:
> Hi,
>
> On 2022-02-17 09:20:56 -0500, Andrew Dunstan wrote:
>> I don't think we have or have ever had a buildfarm animal targeting
>> msys. In general I think of msys as a build environment to create native
>> binaries. But if we want to support targeting msys we should have an
>> animal doing that.
> It's pretty much cygwin. Wouldn't hurt to have a dedicated animal though, I
> agree. We do have a dedicated path for it in configure.ac:
>
> case $host_os in
> ...
>   cygwin*|msys*) template=cygwin ;;



FYI I tested it while in wait mode for something else, and it fell over
at the first hurdle:


running bootstrap script ... 2022-02-18 22:25:45.119 UTC [34860] FATAL: 
could not create shared memory segment: Function not implemented
2022-02-18 22:25:45.119 UTC [34860] DETAIL:  Failed system call was
shmget(key=1407374884304065, size=56, 03600).
child process exited with exit code 1


I'm not intending to put any more effort into supporting it.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andrew Dunstan]

On 2/17/22 15:46, Andres Freund wrote:
> On 2022-02-17 15:23:36 -0500, Andrew Dunstan wrote:
>> Very well. I think the easiest way will be to stash $host_os in the
>> environment and let the script pick it up similarly to what I suggested
>> with MSYSTEM.
> WFM.


OK, here's a patch.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/config/check_modules.pl b/config/check_modules.pl
index cc0a7ab0e7..470c3e9c14 100644
--- a/config/check_modules.pl
+++ b/config/check_modules.pl
@@ -6,6 +6,7 @@
 #
 use strict;
 use warnings;
+use Config;
 
 use IPC::Run 0.79;
 
@@ -19,5 +20,9 @@ diag("IPC::Run::VERSION: $IPC::Run::VERSION");
 diag("Test::More::VERSION: $Test::More::VERSION");
 diag("Time::HiRes::VERSION: $Time::HiRes::VERSION");
 
+# Check that if prove is using msys perl it is for an msys target
+ok(($ENV{__CONFIG_HOST_OS__} || "") eq 'msys',
+   "Msys perl used for correct target")
+  if $Config{osname} eq 'msys';
 ok(1);
 done_testing();
diff --git a/configure b/configure
index ba635a0062..5e3af5c35b 100755
--- a/configure
+++ b/configure
@@ -19453,6 +19453,7 @@ fi
   # installation than perl, eg on MSys, so we have to check using prove.
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for Perl modules required for TAP tests" >&5
 $as_echo_n "checking for Perl modules required for TAP tests... " >&6; }
+  __CONFIG_HOST_OS__=$host_os; export __CONFIG_HOST_OS__
   modulestderr=`"$PROVE" "$srcdir/config/check_modules.pl" 2>&1 >/dev/null`
   if test $? -eq 0; then
 # log the module version details, but don't show them interactively
diff --git a/configure.ac b/configure.ac
index 16167329fc..d00e92357e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2396,6 +2396,7 @@ if test "$enable_tap_tests" = yes; then
   # AX_PROG_PERL_MODULES here, but prove might be part of a different Perl
   # installation than perl, eg on MSys, so we have to check using prove.
   AC_MSG_CHECKING(for Perl modules required for TAP tests)
+  __CONFIG_HOST_OS__=$host_os; export __CONFIG_HOST_OS__
   [modulestderr=`"$PROVE" "$srcdir/config/check_modules.pl" 2>&1 >/dev/null`]
   if test $? -eq 0; then
 # log the module version details, but don't show them interactively

Re: killing perl2host

[Andres Freund]

On 2022-02-17 15:23:36 -0500, Andrew Dunstan wrote:
> Very well. I think the easiest way will be to stash $host_os in the
> environment and let the script pick it up similarly to what I suggested
> with MSYSTEM.

WFM.

Re: killing perl2host

[Andrew Dunstan]

On 2/17/22 15:09, Andres Freund wrote:
> Hi,
>
> On 2022-02-17 14:40:01 -0500, Andrew Dunstan wrote:
>> Sure, that could be done, but what's the issue? Msys2 normally defines
>> MSYSTEM for you - see /etc/msystem which is sourced by /etc/profile.
> It seems not a great idea to me to use different sources of truth about build
> target. And I think it's not hard to get the actual host_os and MSYSTEM to
> disagree:
> - afaics it's quite possible to run configure outside of a login msys shell
> - you could do an msys build in a ucrt shell, but specify 
> --host=x86_64-pc-msys,
>   or the other way round


Very well. I think the easiest way will be to stash $host_os in the
environment and let the script pick it up similarly to what I suggested
with MSYSTEM.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andres Freund]

Hi,

On 2022-02-17 14:40:01 -0500, Andrew Dunstan wrote:
> Sure, that could be done, but what's the issue? Msys2 normally defines
> MSYSTEM for you - see /etc/msystem which is sourced by /etc/profile.

It seems not a great idea to me to use different sources of truth about build
target. And I think it's not hard to get the actual host_os and MSYSTEM to
disagree:
- afaics it's quite possible to run configure outside of a login msys shell
- you could do an msys build in a ucrt shell, but specify --host=x86_64-pc-msys,
  or the other way round

There's probably also some stuff about cross building from linux, but that
doesn't matter much, because right now wine doesn't get through even the base
regression tests (although it gets through initdb these days, which is nice).


> > Or the test just implemented in
> > configure, as I suggested.
> >
> 
> No, because we don't know which perl will be invoked by $PROVE. That's
> why we set up check_modules.pl in the first place.

Ah.

Greetings,

Andres Freund

Re: killing perl2host

[Andrew Dunstan]

On 2/17/22 13:10, Andres Freund wrote:
> On 2022-02-17 13:08:01 -0500, Andrew Dunstan wrote:
 perhaps something like:


     my $msystem = $ENV{MSYSTEM} || 'undef';

     die "incompatible perl" if $Config{osname} eq 'msys' && $msystem ne
 'MSYS';
>>> Why tests MSYSTEM instead of $host_os?
>> Is that available in check_modules.pl? AFAICT it's an unexported shell
>> variable.
> No, but it could just be passed to it? 


Sure, that could be done, but what's the issue? Msys2 normally defines
MSYSTEM for you - see /etc/msystem which is sourced by /etc/profile.


> Or the test just implemented in
> configure, as I suggested.
>

No, because we don't know which perl will be invoked by $PROVE. That's
why we set up check_modules.pl in the first place.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andres Freund]

On 2022-02-17 13:08:01 -0500, Andrew Dunstan wrote:
> >> perhaps something like:
> >>
> >>
> >>     my $msystem = $ENV{MSYSTEM} || 'undef';
> >>
> >>     die "incompatible perl" if $Config{osname} eq 'msys' && $msystem ne
> >> 'MSYS';
> > Why tests MSYSTEM instead of $host_os?

> Is that available in check_modules.pl? AFAICT it's an unexported shell
> variable.

No, but it could just be passed to it? Or the test just implemented in
configure, as I suggested.

Greetings,

Andres Freund

Re: killing perl2host

[Andrew Dunstan]

On 2/17/22 12:12, Andres Freund wrote:
> Hi,
>
> On 2022-02-17 09:20:56 -0500, Andrew Dunstan wrote:
>> I don't think we have or have ever had a buildfarm animal targeting
>> msys. In general I think of msys as a build environment to create native
>> binaries. But if we want to support targeting msys we should have an
>> animal doing that.
> It's pretty much cygwin. Wouldn't hurt to have a dedicated animal though, I
> agree. We do have a dedicated path for it in configure.ac:
>
> case $host_os in
> ...
>   cygwin*|msys*) template=cygwin ;;
>
>
>
>>> I think this means we should do the msys test in configure, inside
>>>
>>> if test "$enable_tap_tests" = yes; then
>>>
>>> and verify that $host_os != msys.
>> config/check_modules.pl is probably the right place for the test, as it
>> will be running with the perl we should be testing, and is only called
>> if we configure with TAP tests enabled.
> Makes sense.
>
>
>> perhaps something like:
>>
>>
>>     my $msystem = $ENV{MSYSTEM} || 'undef';
>>
>>     die "incompatible perl" if $Config{osname} eq 'msys' && $msystem ne
>> 'MSYS';
> Why tests MSYSTEM instead of $host_os?



Is that available in check_modules.pl? AFAICT it's an unexported shell
variable.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andres Freund]

Hi,

On 2022-02-17 09:20:56 -0500, Andrew Dunstan wrote:
> I don't think we have or have ever had a buildfarm animal targeting
> msys. In general I think of msys as a build environment to create native
> binaries. But if we want to support targeting msys we should have an
> animal doing that.

It's pretty much cygwin. Wouldn't hurt to have a dedicated animal though, I
agree. We do have a dedicated path for it in configure.ac:

case $host_os in
...
  cygwin*|msys*) template=cygwin ;;



> > I think this means we should do the msys test in configure, inside
> >
> > if test "$enable_tap_tests" = yes; then
> >
> > and verify that $host_os != msys.

> config/check_modules.pl is probably the right place for the test, as it
> will be running with the perl we should be testing, and is only called
> if we configure with TAP tests enabled.

Makes sense.


> perhaps something like:
> 
> 
>     my $msystem = $ENV{MSYSTEM} || 'undef';
> 
>     die "incompatible perl" if $Config{osname} eq 'msys' && $msystem ne
> 'MSYS';

Why tests MSYSTEM instead of $host_os?

Greetings,

Andres Freund

Re: killing perl2host

[Andrew Dunstan]

On 2/16/22 21:17, Andres Freund wrote:
> Hi,
>
> On 2022-02-16 14:42:30 -0800, Andres Freund wrote:
>> On February 16, 2022 1:10:35 PM PST, Andrew Dunstan  
>> wrote:
>>> So something like this in Utils.pm:
>>>
>>>
>>> die "Msys targeted perl is unsupported for running TAP tests" if
>>> $Config{osname}eq 'msys';
>> I don't think we should reject msys general - it's fine as long as the 
>> target is msys, no? Msys includes postgres fwiw...



I don't think we have or have ever had a buildfarm animal targeting
msys. In general I think of msys as a build environment to create native
binaries. But if we want to support targeting msys we should have an
animal doing that.


> I think this means we should do the msys test in configure, inside
>
> if test "$enable_tap_tests" = yes; then
>
> and verify that $host_os != msys.
>


config/check_modules.pl is probably the right place for the test, as it
will be running with the perl we should be testing, and is only called
if we configure with TAP tests enabled.

perhaps something like:


    my $msystem = $ENV{MSYSTEM} || 'undef';

    die "incompatible perl" if $Config{osname} eq 'msys' && $msystem ne
'MSYS';


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andres Freund]

Hi,

On 2022-02-16 14:42:30 -0800, Andres Freund wrote:
> On February 16, 2022 1:10:35 PM PST, Andrew Dunstan  
> wrote:
> >So something like this in Utils.pm:
> >
> >
> >die "Msys targeted perl is unsupported for running TAP tests" if
> >$Config{osname}eq 'msys';
> 
> I don't think we should reject msys general - it's fine as long as the target 
> is msys, no? Msys includes postgres fwiw...

I think this means we should do the msys test in configure, inside

if test "$enable_tap_tests" = yes; then

and verify that $host_os != msys.

Greetings,

Andres Freund

Re: killing perl2host

[Andres Freund]

Hi, 

On February 16, 2022 1:10:35 PM PST, Andrew Dunstan  wrote:
>
>On 2/16/22 16:01, Andres Freund wrote:
>> Hi,
>>
>> On 2022-02-16 15:46:28 -0500, Andrew Dunstan wrote:
>>> I suggest that we apply this patch:
>> +1
>>
>>> and if nothing breaks in a few days I will set about a more thorough
>>> removal of perl2host() and adjusting everywhere it's called, and we can
>>> forget that the whole sorry mess ever happened :-)
>> I think we would need an error check against using an msys perl when 
>> targeting
>> native windows, otherwise this'll be too hard to debug.
>
>
>So something like this in Utils.pm:
>
>
>die "Msys targeted perl is unsupported for running TAP tests" if
>$Config{osname}eq 'msys';

I don't think we should reject msys general - it's fine as long as the target 
is msys, no? Msys includes postgres fwiw...


>> And we probably should set that environment variable that might fix in-tree
>> tests? Or reject in-tree builds?
>
>
>I think that's an orthogonal issue, but yes we should probably set it.
>Have you tested to make sure it does what we want? I certainly don't
>want to reject in-tree builds.

I don't think it's quite orthogonal - msys perl uses sane PATH semantics and 
thus doesn't have this problem.

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: killing perl2host

[Andrew Dunstan]

On 2/16/22 16:01, Andres Freund wrote:
> Hi,
>
> On 2022-02-16 15:46:28 -0500, Andrew Dunstan wrote:
>> I suggest that we apply this patch:
> +1
>
>> and if nothing breaks in a few days I will set about a more thorough
>> removal of perl2host() and adjusting everywhere it's called, and we can
>> forget that the whole sorry mess ever happened :-)
> I think we would need an error check against using an msys perl when targeting
> native windows, otherwise this'll be too hard to debug.


So something like this in Utils.pm:


die "Msys targeted perl is unsupported for running TAP tests" if
$Config{osname}eq 'msys';


>
> And we probably should set that environment variable that might fix in-tree
> tests? Or reject in-tree builds?


I think that's an orthogonal issue, but yes we should probably set it.
Have you tested to make sure it does what we want? I certainly don't
want to reject in-tree builds.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: killing perl2host

[Andres Freund]

Hi,

On 2022-02-16 15:46:28 -0500, Andrew Dunstan wrote:
> I suggest that we apply this patch:

+1

> and if nothing breaks in a few days I will set about a more thorough
> removal of perl2host() and adjusting everywhere it's called, and we can
> forget that the whole sorry mess ever happened :-)

I think we would need an error check against using an msys perl when targeting
native windows, otherwise this'll be too hard to debug.

And we probably should set that environment variable that might fix in-tree
tests? Or reject in-tree builds?

Greetings,

Andres Freund