bug-make
[Top][All Lists]
Advanced

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

Re: GNU make 4.3.92 on mingw


From: Paul Smith
Subject: Re: GNU make 4.3.92 on mingw
Date: Tue, 25 Oct 2022 15:33:38 -0400
User-agent: Evolution 3.46.0 (by Flathub.org))

On Tue, 2022-10-25 at 22:13 +0300, Eli Zaretskii wrote:
> > So if we see a difference it must be that there's some OTHER
> > difference not just CRLF.  Or, the test suite comparison has a
> > bug.  I'll have to look more closely at the output.
> 
> I do see differences unrelated to CRLF, see below.

Yes, I failed to explain well.  The framework will do the comparison of
base with log using "modified" versions that strip CRLF etc.

Only IF that comparison of modified versions fails (there's some
difference) will diff(1) be run.  When diff(1) is run, it's run on the
ORIGINAL versions not the modified versions.

So, you won't see an error if the ONLY difference is CRLF.  But if
there's some OTHER difference in addition to CRLF then you'll see both
that other difference AND the CRLF difference.


Anyway, I've discovered the basis of (most of?) the differences thanks
to the results files in the error file.

When Bruno builds for MinGW he builds inside of the Cygwin context,
using a MinGW "cross-compiler".  So he runs ./configure etc. in Cygwin
but with CC=x86_64-w64-mingw32-gcc installed in Cygwin.

Then to run the tests, he again runs it from the Cygwin shell, using
the Cygwin version of Perl.  We can see that from the test log:

    Running tests for GNU Make on cygwin
                                  ^^^^^^

This value is obtained from Perl's $^O variable containing the "host"
OS.  Many of the tests use this value or values derived from it to
decide whether to run tests in a "Windows context" or in a "POSIX
context".  When we run tests in a POSIX context we assume we have all
the POSIX stuff including POSIX fork/exec, paths, etc. not the MinGW
CreateProcess, Windows paths, etc.  "cygwin" is assumed to be a POSIX
context.

The test suite just doesn't handle this kind of "cross-built"
environment right now, where Perl has a different target than GNU make.
Probably we should be determining the value of $(MAKE_HOST) to decide
how to run the tests, rather than the value of Perl's $^O variable. 
But, maybe in some places we'd need both.



reply via email to

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