Date:	Mon, 16 Sep 1996 10:34:16 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	djgpp-workers AT delorie DOT com
Subject:	SHELL=/bin/sh lines in Makefiles
Message-Id:	<Pine.SUN.3.91.960916101936.21681E-100000@is>
Mime-Version:	1.0

I got some feedback from people who tried the preliminary version of Make
3.74 and decided that it will be A Good Thing to NOT ignore the SHELL=
lines after all.  The latest version does the following: if the Makefile
sets $SHELL, it looks for that name with the usual executable extensions,
and failing that, further searches for the basename of the shell along the
$PATH.  For example, if you have SHELL=/bin/sh, then it will look for
"/bin/sh.exe", "/bin/sh.com" etc., then will look along the $PATH for
"sh.exe", "sh.com"  etc.  This is also consistent with what the latest 
version of `spawn' and `system' do when they are presented with a 
Unix-style script that says "#! /bin/sh" at its first line.

Since most of the people who have unixy shells installed belong to this 
group, I expect us to be the most affected by this change.  In 
particular, to see that a ported Makefile works for everybody else, we 
will have to either edit out the SHELL= line or (better) set MAKESHELL = 
command.com before running Make.  My testing indicates that most DOSified 
Makefiles don't need the shell anyway (since most commands are executed 
by Make directly, especially because the latest port calls `system' which 
does most of the work itself), so the problem is not as acute as it might 
sound on first reading.

Please tell me if the above logic might get us into trouble somehow.

A question on a related issue: is it safe to assume that the $SHELL is 
the same for the entire Makefile, and that it is therefore known by the 
time Make have read all of the Makefile?  Currently, I look at the shell 
name to decide whether it is a unixy one once per command, but that seems 
a wasteful approach.

- Raw text -