Re: GNU Make 4.4.0.91 on Cygwin

2023-02-20 Thread Eli Zaretskii 
> From: Paul Smith 
> Cc: br...@clisp.org, bug-make@gnu.org
> Date: Mon, 20 Feb 2023 10:36:07 -0500
> 
> Of course "testing on Windows" can mean many different things as there
> are so many possible environments "on Windows".  I only run one Windows
> environment: (a) Windows 10/11 in a VM, (b) using Visual Studio as the
> compiler, (c) using .\build_w32.bat in cmd.exe to do the build, (d)
> running tests from within cmd.exe via ".\WinRel\gnumake.exe check", (e)
> with Git for Windows bin directory on my PATH so I have access to a
> bunch of POSIX tools during the test run.
> 
> It definitely doesn't fail for me in that configuration.
> 
> > Maybe it could work if you link Make statically, or if you copy the
> > dependency DLLs into a system directory where Windows looks
> > regardless of PATH.  But in general, emptying PATH on Windows is not
> > very useful.
> 
> That's missing the point of the test.  Even on POSIX it's useless to
> start a process with an empty PATH, but that's not what the test is
> for.  See https://savannah.gnu.org/bugs/index.php?57674 to read the
> background: on a POSIX system if PATH is not set a default PATH is used
> when we run execvp() and that's what this is testing.
> 
> I don't really know what happens in this situation on Windows, but
> something must happen.

Is your VS-built Make statically linked, or does it have dependencies
on DLLs, such as Guile?  If the latter, in which directories are those
DLLs kept?

My problem with an empty PATH is that the dependency DLLs cannot be
found, and Make simply won't start, because the Windows loader won't
let it.  And even if I work around this by copying the DLLs to the
same directory as the Make executable, there's no point to this test
on Windows, since there's no "default PATH used by execvp" on
MS-Windows.  Moreover, execvp on Windows is emulated (quite poorly,
btw) anyway.

IOW, this Posix feature makes no sense on Windows, so I decided long
ago not to try too hard to run this test.

> It's possible that it works for me because I'm using cmd.exe as the
> shell, and echo is a shell built-in there, and so the fact that PATH is
> empty is irrelevant.

I also use cmd.exe, I just don't have any Git-related Unix programs on
PATH, including Bash and MSYS executables that come with it.  The test
suite runs Perl, so it is very much possible that in your environment,
the Perl that runs is an MSYS perl, not a native Windows perl, in
which case what you get is the Cygwin emulation of Posix (since MSYS
is nothing other than a fork of Cygwin).

In my environment, the perl being used for the test suite is a native
Windows perl (ActiveState Perl).  And any Unix tools the test suite
uses, like 'touch' etc. are all native Windows builds, not MSYS
builds.

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-20 Thread Paul Smith 
On Mon, 2023-02-20 at 14:47 +0200, Eli Zaretskii wrote:
> How do you conclude that this "works on Windows"?

Before I make a release I test on various systems and the regression
test suite must pass with no failures.  One of the systems I test on is
Windows, so if a release comes out and a test is not conditionalized to
not run on that system in that release, you can assume it worked for
me.

Of course "testing on Windows" can mean many different things as there
are so many possible environments "on Windows".  I only run one Windows
environment: (a) Windows 10/11 in a VM, (b) using Visual Studio as the
compiler, (c) using .\build_w32.bat in cmd.exe to do the build, (d)
running tests from within cmd.exe via ".\WinRel\gnumake.exe check", (e)
with Git for Windows bin directory on my PATH so I have access to a
bunch of POSIX tools during the test run.

It definitely doesn't fail for me in that configuration.

> Maybe it could work if you link Make statically, or if you copy the
> dependency DLLs into a system directory where Windows looks
> regardless of PATH.  But in general, emptying PATH on Windows is not
> very useful.

That's missing the point of the test.  Even on POSIX it's useless to
start a process with an empty PATH, but that's not what the test is
for.  See https://savannah.gnu.org/bugs/index.php?57674 to read the
background: on a POSIX system if PATH is not set a default PATH is used
when we run execvp() and that's what this is testing.

I don't really know what happens in this situation on Windows, but
something must happen.

It's possible that it works for me because I'm using cmd.exe as the
shell, and echo is a shell built-in there, and so the fact that PATH is
empty is irrelevant.

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-20 Thread Eli Zaretskii 
> From: Paul Smith 
> Date: Sun, 19 Feb 2023 14:59:35 -0500
> 
> On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote:
> > All "Device or resource busy" failures are gone. Only the 1 failure
> > in category 'misc/general4' is still present.
> 
> Hm.  This is a test of this:
> https://savannah.gnu.org/bugs/index.php?57674
> 
> which explicitly removes PATH from the environment completely.  It
> should use a default PATH, which should mean "echo" works even so.  I'm
> not really sure how this should react on a cygwin system, but I guess
> since it behaves properly on Windows and POSIX it should work on cygwin
> as well.  I'll have to figure out why only cygwin isn't working.

How do you conclude that this "works on Windows"?  In my testing, it
doesn't, and I therefore disable this test on Windows:

  # SV 57674: ensure we use a system default PATH if one is not set
  # This cannot work on MS-Windows, because PATH is used to find
  # shared libraries against which Make was built.
  if ($port_type ne 'W32') {
  delete $ENV{PATH};
  run_make_test(q!
  a: ; @echo hi
  !,
'', "hi\n");
  }

Maybe it could work if you link Make statically, or if you copy the
dependency DLLs into a system directory where Windows looks regardless
of PATH.  But in general, emptying PATH on Windows is not very useful.

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-19 Thread Paul Smith 
On Sun, 2023-02-19 at 17:20 -0500, Ken Brown wrote:
> > Hm.  This is a test of this:
> > https://savannah.gnu.org/bugs/index.php?57674
> > 
> > which explicitly removes PATH from the environment completely.  It
> > should use a default PATH, which should mean "echo" works even so. 
> > I'm not really sure how this should react on a cygwin system, but I
> > guess since it behaves properly on Windows and POSIX it should work
> > on cygwin as well.  I'll have to figure out why only cygwin isn't
> > working.
> 
> All tests pass on my Cygwin 3.4.6 system.

Well... if it works with current releases I guess I don't feel like
spending a lot of time trying to suss out a very obscure issue (like
running make with no PATH set) on an older version of Cygwin.

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-19 Thread Ken Brown 

On 2/19/2023 2:59 PM, Paul Smith wrote:

On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote:

All "Device or resource busy" failures are gone. Only the 1 failure
in category 'misc/general4' is still present.


Hm.  This is a test of this:
https://savannah.gnu.org/bugs/index.php?57674

which explicitly removes PATH from the environment completely.  It
should use a default PATH, which should mean "echo" works even so.  I'm
not really sure how this should react on a cygwin system, but I guess
since it behaves properly on Windows and POSIX it should work on cygwin
as well.  I'll have to figure out why only cygwin isn't working.


All tests pass on my Cygwin 3.4.6 system.

Ken

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-19 Thread Paul Smith 
On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote:
> All "Device or resource busy" failures are gone. Only the 1 failure
> in category 'misc/general4' is still present.

Hm.  This is a test of this:
https://savannah.gnu.org/bugs/index.php?57674

which explicitly removes PATH from the environment completely.  It
should use a default PATH, which should mean "echo" works even so.  I'm
not really sure how this should react on a cygwin system, but I guess
since it behaves properly on Windows and POSIX it should work on cygwin
as well.  I'll have to figure out why only cygwin isn't working.

GNU Make 4.4.0.91 on Cygwin

2023-02-19 Thread Bruno Haible 
On Cygwin (running in Windows 10), the results are much better than those
of 4.4.0.90 :

All "Device or resource busy" failures are gone. Only the 1 failure in
category 'misc/general4' is still present.



makeerror-4.4.0.91-x86_64-pc-cygwin-gcml.tar.gz
Description: application/compressed-tar