bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Make 4.4.0.91 on Cygwin


From: Eli Zaretskii
Subject: Re: GNU Make 4.4.0.91 on Cygwin
Date: Mon, 20 Feb 2023 18:54:02 +0200

> From: Paul Smith <psmith@gnu.org>
> Cc: bruno@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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]