make-w32
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]