[Top][All Lists]

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

Re: GNU Make on Cygwin

From: Paul Smith
Subject: Re: GNU Make on Cygwin
Date: Mon, 20 Feb 2023 10:36:07 -0500
User-agent: Evolution 3.46.4 (by Flathub.org)

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

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.

reply via email to

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