[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Useful patch for GNUmake on Windows
From: |
Greg Chicares |
Subject: |
Re: Useful patch for GNUmake on Windows |
Date: |
Fri, 13 Sep 2002 10:27:06 -0400 |
Rob Tulloh wrote:
[reformatted]
>
> Martin Oberhuber wrote:
> >
> > On Windows, it is often unclear what shell "make" uses. The default
> > behavior (as of make-3.78.1) is to search for a program called
> > "sh.exe" in the PATH; if it is found, this one is used, otherwise
> > the Windows Commandprompt (cmd.exe) is used.
According to the manual
http://www.gnu.org/manual/make/html_mono/make.html#SEC46
"In MS-DOS, GNU make searches for the shell in the following places
1.In the precise place pointed to by the value of SHELL.
For example, if the makefile specifies `SHELL = /bin/sh',
make will look in the directory `/bin' on the current drive.
2.In the current directory.
3.In each of the directories in the PATH variable, in order."
as long as SHELL is set in the makefile as recommended here
http://www.gnu.org/manual/make/html_mono/make.html#SEC117
"General Conventions for Makefiles
Every Makefile should contain this line:
SHELL = /bin/sh "
> > My patch (I called it TRY_LOCAL_SHELL_FIRST) tries to find sh.exe
> > first in the same directory where make.exe itself is located.
Assuming the source agrees with the manual, it sounds like
you're augmenting the above search by adding
0. In the same directory where make.exe itself is located.
either at the top of the list or at least before #3.
> > This gives the user the freedom to define the PATH and add any
> > shells he likes into the PATH, but still sort of control which
> > sh.exe will be used.
>
> Isn't this already enabled through setting of SHELL? Wouldn't it
> be preferable to just define SHELL to be the full path to the
> sh.exe rather than adding another search criteria?
That would seem best. To comply with the
"General Conventions for Makefiles"
it can be set in the environment, according to the manual:
"on MS-DOS and MS-Windows the value of SHELL in
the environment *is* used"
> I am not fully opposed to this patch,
It's not an unreasonable heuristic. But it seems
to turn a threefold rule into a fourfold rule, which
was not the only rule that comes into play. I'd say
things are already complex enough.
> but I wonder if the current functionality
> in make is sufficient to enable this sort of desired behavior.
> It's not exactly equivalent -- you have to define SHELL in the
> environment -- but it has the same result of giving the user full
> control over what path to SHELL they desire.
I'll admit that I'm doing the following in order
to make 'make' use 'zsh':
place a copy of zsh, named 'sh.exe', in /usr/bin
set environment variables
COMSPEC='C:\usr\bin\sh.exe'
ComSpec='C:\usr\bin\sh.exe'
no "SHELL = /bin/sh" in makefiles
Probably there's a better way, but this way 'works'.
(Two different capitalizations of 'comspec' seemed
to be needed for win95 vs. win2k.) Perhaps other
people have found other ways that 'just work' too.
Some of these ways may be brittle in the sense that
there are so many paths through the rules:
SHELL not set: COMSPEC used
SHELL defined either in makefile or environment
MAKESHELL defined either in makefile or environment
runtime check whether file pointed to by SHELL exists
repeat check with various suffixes
repeat check in several locations,
but only if SHELL is set in the makefile
so we should be careful about changing the rules
lest we break working code. If a fourth search
rule is added, at least it should come fourth in
priority in order to avoid breaking brittle stuff
people may have done.
Even after reading the manual on this topic several
times and playing with various settings, I can't
recite what it all means. I'm tempted to propose a
patch to add a new directive
.IGNORE_MS_FUNKINESS
with the effect
Suppress all the oddball dos and windows rules: just
treat me like I'm *nix even under 32-bit windows.
Perhaps that could be called '.WIN32' without
upsetting rms because it really would be a win.
- Useful patch for GNUmake on Windows, Martin Oberhuber, 2002/09/12
- RE: Useful patch for GNUmake on Windows, Martin Oberhuber, 2002/09/18
- RE: Useful patch for GNUmake on Windows, Paul D. Smith, 2002/09/18
- Re: Useful patch for GNUmake on Windows, Earnie Boyd, 2002/09/18
- Re: Useful patch for GNUmake on Windows, Paul D. Smith, 2002/09/18
- Re: Useful patch for GNUmake on Windows, Greg Chicares, 2002/09/18
- Re: Useful patch for GNUmake on Windows, Paul D. Smith, 2002/09/18
- Re: Useful patch for GNUmake on Windows, Rob Tulloh, 2002/09/18
- Re: Useful patch for GNUmake on Windows, Eli Zaretskii, 2002/09/19
- Re: Useful patch for GNUmake on Windows, Eli Zaretskii, 2002/09/19
- Re: Useful patch for GNUmake on Windows, Earnie Boyd, 2002/09/19