Perhaps my sample was too simple. If I supply a Makefile that can work with or without sh.exe presence (on any user machines) I must rely on what make knows about the shell. Forcing SHELL= obviously does not work. Another example, Cygwin which provides a sh.exe also dir.exe which gives a different output. If SHELL is sh.exe or cmd.exe output is different
ifeq ($(SHELL),sh.exe) LIST=$(shell dir) else LIST=$(shell dir /b) endif For my need, which is to have a gnumake coming with tcc.exe, I know how to automatically patch and build make with sh.exe replaced by cmd.exe in source file. So it's not a problem for me. I just wanted to point out something which I find not consistency (aka a bug). I'm more interested to have my patches for built_w32.bat and src/config.h.W32.template integrated to the next release. Anyway many thanks you're your time and patience. C. -----Original Message----- From: Eli Zaretskii [mailto:[email protected]] Sent: Thursday, January 23, 2020 20:26 To: [email protected] Cc: [email protected] Subject: Re: Why SHELL defaults to sh.exe > From: "Christian Jullien" <[email protected]> > Date: Thu, 23 Jan 2020 20:18:17 +0100 > > Hum I see! It only a problem if I want to execute something if a sh.exe > exists. > > search: > ifeq ($(SHELL),sh.exe) > grep something file > else > find "something" file > endif If you want to depend on the value of $(SHELL), set it explicitly in the Makefile. In any case, the above logic is flawed, because 'grep' can be available on Windows as well (I certainly have it here), and 'find' could actually invoke a ported GNU 'find'. IME, it is much better to have Make variables for such commands, and let users set them from the Make command line.
