> From: John Freeman <[email protected]> > Date: Sat, 4 Sep 2021 10:11:19 -0500 > > I previously sent this message to Eli Zaretskii, whose [EZWinPorts] > (https://sourceforge.net/projects/ezwinports/files/) binary I am using. He > asked me to move this conversation > here.
Thanks for taking it here, this is the right place for such discussions. > I'm trying to choose the shell for my Makefile recipes when I run > EZWinPorts's Windows port of Make 4.3 > (without Guile, [installed by > Scoop](https://github.com/ScoopInstaller/Main/blob/master/bucket/make.json)), > but can't seem to get it to work. First, I'd like to emphasize that the binaries on that site are straight OOTB builds of the GNU Make sources, following the documented build procedure. There are no source-level changes, nor any special build-time tricks. So what I describe below is how the official GNU Make behaves when compiled natively for MS-Windows. > For example, I'm running on Windows with PowerShell installed and on the > `PATH`. If I make a target whose > recipe is just "`ls`", I get this error: > > process_begin: CreateProcess(NULL, ls, ...) failed. > make (e=2): The system cannot find the file specified. > make: *** [Makefile:4: ls] Error 2 > > That's fine. Maybe it's using `cmd` as the shell for that line (but it really > looks like it ignores all shells and > directly calls Windows's equivalent of `popen`). Then I run through the > different [options] > (https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html) > for choosing the shell as > laid out in the docs. GNU Make avoids calling the shell for commands that don't require any shell functionality it knows about. This is how GNU Make works on all platforms, and the Windows port doesn't change that. So if you don't have ls.exe or ls.bat or ls.cmd somewhere on Path, the above is expected, regardless of the value of SHELL in the Makefile. (You can see from the error message that it tried to invoke 'ls'; the shell is nowhere in the call it shows that failed.) To trigger the use of a shell, you need to use some feature on the command line that needs a shell. For example, redirection or some fancy quoting. > - I can see that `ComSpec` is set in my default environment. In PowerShell, I > can read it as `$env:ComSpec > ` or `$env:COMSPEC`, but in a Makefile, it is only available as `${ComSpec}`. > If I remove and re-add the > variable under the name `$env:COMSPEC`, it becomes available in the Makefile > as `${COMSPEC}`, but I > still get the same error from the `ls` recipe. I'm not sure I understand why you think this is a problem. Environment variables are case-insensitive on MS-Windows, so why does it matter whether you have ComSpec or COMSPEC? > How can I achieve my goal? What is your goal, exactly? I don't think you stated it, or maybe I missed that.
