Re: GNU make 4.3.92 on mingw

[Eli Zaretskii]

> From: Paul Smith <psmith@gnu.org>
> Cc: bruno@clisp.org, bug-make@gnu.org
> Date: Tue, 25 Oct 2022 14:10:25 -0400
> 
> On Tue, 2022-10-25 at 19:37 +0300, Eli Zaretskii wrote:
> > > A lot of these seem to be CRLF errors in the diff, where it would
> > > otherwise match.  I know that the test framework does some
> > > manipulation of CRLF.
> > 
> > If the test suite runs Diff, it should invoke it with the
> > "--strip-trailing-cr" switch, I think.  Because Cygwin's (and MSYS's)
> > Diff doesn't use Windows text-mode I/O.
> 
> OK I looked into the test suite to remind myself what it does.
> 
> First it compares the base and the log file directly; if they are equal
> we're done.  If they're not equal we manipulate them by (a) converting
> backslash to slash and (b) converting CRLF to LF, then we compare them
> again.  If they're now the same, declare victory.  If they're still
> different, then we invoke diff on the original versions.
> 
> 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.

> I don't want to just add that diff switch because it's a GNU diff
> switch and won't work on systems without GNU diff (BSD, etc.)  If I
> wanted to use it I'd need to first check that it was available.  Which
> could be done of course.

MinGW uses only GNU Diff.

Here are the differences I see in the files posted by Bruno.  They
seem to show problems unrelated to EOL format:

> *** work/features/archives.base.1     Tue Oct 25 03:35:39 2022
> --- work/features/archives.log.1      Tue Oct 25 03:35:39 2022
> ***************
> *** 1,2 ****
> ! x86_64-w64-mingw32-ar -rvU libxx.a a2.o
>   a - a2.o
> --- 1,4 ----
> ! x86_64-w64-mingw32-ar -rvU libxx.a a1.o

> ! r - a1.o
> ! x86_64-w64-mingw32-ar -rvU libxx.a a2.o

>   a - a2.o

This (and other similar diffs in features/archives) seem to indicate
that x86_64-w64-mingw32-ar behaves unexpectedly?

> *** work/features/errors.base.3       Tue Oct 25 03:35:51 2022
> --- work/features/errors.log.3        Tue Oct 25 03:35:51 2022
> ***************
> *** 1,3 ****
> ! ./foobarbazbozblat xx yy
> ! make: ./foobarbazbozblat: No such file or directory
> ! make: [work/features/errors.mk.2:2: one] Error 127 (ignored)
> --- 1,4 ----
> ! ./foobarbazbozblat xx yy

> ! process_begin: CreateProcess(NULL, ./foobarbazbozblat xx yy, ...) failed.

> ! make (e=2): The system cannot find the file specified.


> ! make: [work/features/errors.mk.2:2: one] Error 2 (ignored)


This is a real issue; I patch this (and other) tests to expect the
error messages produced by Make on Windows.

> *** work/features/include.base.36     Tue Oct 25 03:36:06 2022
> --- work/features/include.log.36      Tue Oct 25 03:36:06 2022
> ***************
> *** 5,8 ****
>   GNUmakefile
>   makefile
>   Makefile
> ! make: 'all' is up to date.
> --- 5,9 ----
>   GNUmakefile
>   makefile
>   Makefile
> ! makefile.mak
> ! make: 'all' is up to date.


This seems to be because Bruno's port of Make is not recognized as
"W32", because features/include does expect makefile.mak then:

  if ($port_type eq 'W32') {
      $defaults = "GNUmakefile\nmakefile\nMakefile\nmakefile.mak";
  } else {
      $defaults = "GNUmakefile\nmakefile\nMakefile";
  }

> *** work/features/jobserver.base.5    Tue Oct 25 03:36:07 2022
> --- work/features/jobserver.log.5     Tue Oct 25 03:36:07 2022
> ***************
> *** 1,2 ****
> ! make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> ! make[1]: Nothing to be done for 'foo'.
> --- 1 ----
> ! make: *** Unknown jobserver auth style 'pipe'.  Stop.


Same here: this test was not supposed to be run for the "W32" port.

> *** work/features/jobserver.base.6    Tue Oct 25 03:36:08 2022
> --- work/features/jobserver.log.6     Tue Oct 25 03:36:08 2022
> ***************
> *** 1,6 ****
> ! make: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: warning: -j1 forced in submake: resetting jobserver mode.
>   hi
> ! make[1]: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> --- 1,6 ----
> ! make: Entering directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make[1]: Entering directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make[1]: warning: -j1 forced in submake: resetting jobserver mode.

>   hi
> ! make[1]: Leaving directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'

> ! make: Leaving directory 
> 'C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests'


This seems to be due to inconsistencies in file naming between Make
and some other program (Perl? Bash?).  Similar failures are seen in
some other failed tests.

> *** work/features/output-sync.base.11 Tue Oct 25 03:36:25 2022
> --- work/features/output-sync.log.11  Tue Oct 25 03:36:25 2022
> ***************
> *** 1,8 ****
> ! make[1]: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! d1 stderr
> ! d1 stdout
> ! make[1]: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! make[1]: Entering directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> ! d2 stderr
> ! d2 stdout
> ! make[1]: Leaving directory '/home/bruno/make-4.3.92/build-mingw64/tests'
> --- 1,5 ----
> ! make: *** Recursive variable 'MAKEFLAGS' references itself (eventually).  
> Stop.

> ! make: *** Recursive variable 'MAKEFLAGS' references itself (eventually).  
> Stop.

> ! make: *** [work/features/output-sync.mk.10:3: t1] Error 2

> ! make: *** Waiting for unfinished jobs....

> ! make: *** [work/features/output-sync.mk.10:4: t2] Error 2


Strange errors.  Perhaps again because -j works unexpectedly?

> *** work/functions/abspath.base       Tue Oct 25 03:37:19 2022
> --- work/functions/abspath.log        Tue Oct 25 03:37:19 2022
> ***************
> *** 0 ****
> --- 1,13 ----
> + work/functions/abspath.mk:15: /: abspath="C:/"

> + work/functions/abspath.mk:19: ///: abspath="//"

> + work/functions/abspath.mk:23: /.: abspath="C:/"

> + work/functions/abspath.mk:27: ///.: abspath="//"

> + work/functions/abspath.mk:31: /./: abspath="C:/"

> + work/functions/abspath.mk:35: /.///: abspath="C:/"

> + work/functions/abspath.mk:39: /..: abspath="C:/"

> + work/functions/abspath.mk:43: ///..: abspath="//"

> + work/functions/abspath.mk:47: /../: abspath="C:/"

> + work/functions/abspath.mk:51: /..///: abspath="C:/"

> + work/functions/abspath.mk:56: /foo/bar/..: abspath="C:/foo"

> + work/functions/abspath.mk:60: /foo/bar/../../../baz: abspath="C:/baz"

> + work/functions/abspath.mk:64: /foo/bar/../ /..: abspath="C:/foo C:/"


These are again due to mismatches in file-name handling.

> *** work/functions/realpath.base.1    Tue Oct 25 03:37:29 2022
> --- work/functions/realpath.log.1     Tue Oct 25 03:37:29 2022
> ***************
> *** 0 ****
> --- 1,7 ----
> + work/functions/realpath.mk.1:3: C:/ != C:/


> + work/functions/realpath.mk.1:7: C:/ != C:/


> + work/functions/realpath.mk.1:11: C:/ != C:/


> + work/functions/realpath.mk.1:15: C:/ != C:/


> + work/functions/realpath.mk.1:19: C:/ != C:/


> + work/functions/realpath.mk.1:23: C:/ != C:/


> + work/functions/realpath.mk.1:27: 
> C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests C:/ != 
> C:/cygwin64/home/bruno/make-4.3.92/build-mingw64/tests C:/



And here there seem to be one CR too many?

> *** work/functions/wildcard.base.6    Tue Oct 25 03:37:34 2022
> --- work/functions/wildcard.log.6     Tue Oct 25 03:37:34 2022
> ***************
> *** 1 ****
> ! /
> --- 1 ----
> ! 

I patched this part to expect a Windows C:/ root directory.

> *** work/misc/bs-nl.base.3    Tue Oct 25 03:37:36 2022
> --- work/misc/bs-nl.log.3     Tue Oct 25 03:37:36 2022
> ***************
> *** 1,2 ****
> ! squ\
> ! ote
> --- 1 ----
> ! squ\ ote

This test should not be run on Windows.

Etc. etc.: I think Bruno needs to take a look at each of the diffs and
eliminate at least the trivial ones: those which have to do with his
testing environment, such as the fact that the W32 port is not
recognized, that absolute file names are supported inconsistently,
etc.