> From: "grischka" <[EMAIL PROTECTED]> > Date: Sat, 6 May 2006 16:32:05 +0200 > > > > Also what I vote for is to remove the dependency of $(SHELL) on > > > the PATH setting on the user's computer. > > > I'm not sure I understand; can you elaborate? > > GNU make docs write: > > > Unlike most variables, the variable SHELL is never set from the > > environment. This is because the SHELL environment variable is used > > to specify your personal choice of shell program for interactive use. > > > It would be very bad for personal choices like this to affect the > > functioning of makefiles.
On Windows, this makes much less sense, since SHELL is normally not set, and so if a user sets it, it is usually not for interactive use, but for programs, such as Make, which do look at SHELL. > The same is true for the PATH setting as its a personal choice also. > If someone wants to build from sources, make must work all the same > regardless of whether personally s/he has SH in the PATH or not. How can it ``work all the same'' when cmd.exe and sh.exe are two _very_ different shells, with two very different sets of behaviors? It is IMO a practical impossibility to have identical behavior with and without sh.exe installed, unless the Makefile forces use of cmd.exe by saying SHELL=cmd.exe. And in that case, Make already does The Right Thing: it uses cmd.exe even if sh.exe is found on PATH. The question here is: What should the Windows port use as the default shell if the Makefile doesn't specify any value for SHELL? The Posix version uses /bin/sh as the default, but on Windows this name will not work, in general. The current code emulates this Posix feature by looking for sh.exe along the PATH, which is quite close. What do you suggest to do instead? use cmd.exe? _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
