Follow-up Comment #9, bug #30714 (project make):
"But this is normal behavior on Windows."
It depends on what you consider "normal". It's normal for CreateProcess, of
course, but this is not how make should work. I don't see any reason why
Windows version should behave differently than Unix version, and I believe
that Unix version does not look for a command in the directory where 'make' is
installed in the first place. This behavior is also not documented in make
manual. Manual states that recipe lines "are executed by invoking a new
subshell for each line", so one would expect selected shell's behavior: look
at current working directory then search through PATH. The shortcut taken here
by not running the shell is wrong, because the shell would interpret the
command differently.
As for shell's command line limit: it doesn't really matter, since this is
the shell's limitation and the Makefile maintainer should be aware of limits
of the selected shell.
"Why is this wrong?"
It's wrong, because it doesn't work the way it is supposed to work. 'make'
claims to support custom shell selection by setting $(SHELL), but its value is
ignored. It is not used for running commands, not even $(SHELL) $(.SHELLFLAGS)
<recipe line> as 'make' claims to do.
I propose the following approach:
1. Try to find a specific program to run the same way the shell would do,
i.e. current working directory and then through PATH.
2. If the program cannot be found, run $(SHELL) $(.SHELLFLAGS) <recipe line>,
as I believe 'make' works on Unix.
This would make 'make' consistent on Unix and Windows.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?30714>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
