Dear Eli, >From your explanation, it seems there is something broken at least with make-4.3. Here is what I have done: cmd> tar xvzf make-4.3.tar.gz <= unmodified from Git cmd> cd make-4.3 cmd> build_w32.bat ... .\WinRel build succeeded. 1 file(s) copied. 1 file(s) copied.
Reduce Windows env down to the minimum: set Path=C:\WINDOWS\system32;C:\WINDOWS set INCLUDE= set LIB= set SHELL= set HOME= Looking for sh of bash somewhere cmd>sh 'sh' is not recognized as an internal or external command, operable program or batch file. cmd>bash 'bash' is not recognized as an internal or external command, operable program or batch file. cmd>WinRel cmd>dir *.exe Volume in drive F is New Volume Volume Serial Number is 12C9-E1B4 Directory of F:\make-4.3\WinRel 2020-01-23 15:39 336,384 gnumake.exe Now the test: cmd>type Makefile all: @echo $(SHELL) cmd>.\gnumake sh.exe <=== Argl!! -----Original Message----- From: Eli Zaretskii [mailto:e...@gnu.org] Sent: Thursday, January 23, 2020 15:33 To: jull...@eligis.com Cc: make-w32@gnu.org Subject: Re: Why SHELL defaults to sh.exe > From: "Christian Jullien" <eli...@orange.fr> > Date: Thu, 23 Jan 2020 11:27:53 +0100 > > I wonder why Windows native gnumake.exe defaults to sh.exe ? Historical reasons. > Building gnumake.exe with build_w32.bat (which defaults to cl.exe) still uses sh.exe while IMHO it should > default to cmd.exe It only defaults to sh.exe if it finds one on PATH. If you are using native Windows tools, why would you have sh.exe on PATH? there are no known good native Windows ports of any Unixy shell, AFAIK, only broken ones. If you don't have sh.exe on PATH, GNU Make on Windows will use cmd.exe. > In an ideal world, I should be able to get for example all .c source files with: > > > > FILES = $(shell dir /b *.c) In GNU Make, you have the $wildcard function instead, so no need to use the shell in this case.