[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Useful patch for GNUmake on Windows

From: Rob Tulloh
Subject: Re: Useful patch for GNUmake on Windows
Date: Wed, 18 Sep 2002 09:56:38 -0700 (PDT)


I think has already been pointed out that Win32 handles SHELL no

differently that other environments. The only catch is that most Unix

environments would set SHELL to something like /bin/sh and be

done. On Windows, this is less effective because there is no concept

like /bin.


In past projects, I have worked around this scenario by

saing that SHELL should be set to sh.exe (for Windows) and

then using a make variable like TOOL_ROOT to specify where

on a given machine the compiler and tools should be found. In

this way, each user's machine can be different. By editing a single

variable, you can customize the environment setting for a given

build environment. If you like, you can even let this variable be

pulled from the environment to avoid that users of the build environment

should edit any makefiles.

One caveat is that you must take care with PATH and Path

to ensure that no unintended user environment creeps into the path unless

you desire this to happen. To ensure that PATH/Path are set as

you want, you should set the values in your global make configuration

so that all sub-makes and sub-shells get the value of PATH and Path

that  you expect. Note I only mention PATH vs Path because of

the way that Bourne shell implementations will usually want PATH

to be set whereas Win32 systems are happy with virtually any

spelling as Win32 does not know the difference.

However, Path is the more common spelling that you find in practice.

Where both variables must be managed, I have handled it like this:


PATH = $(VAR1):$(VAR2):$(VAR3)

Path = $(PATH)


In this way, you can manage the settings for both Windows and sh.exe

at the same time. This is also more likely to be portable since existing

Unix-based environments will already be managing PATH and you can

avoid to change everything by simply making Path the same as PATH.

Windows specific stuff can be added to PATH if needed and portability

is retained. For example, you could say something like this if you wanted to:


ifeq ($(INTERP),win32)

PATH += $(SystemRoot)/system32



Going back to the orginal question about the patch, I guess it will

depend on whether or not we wish to suggest that users control how

make finds sh.exe through path or if we want to add an additional

feature like is proposed. I have always been happy to let make sort things

out through path settings.


My $.02,




 "Paul D. Smith" wrote:

%% Greg Chicares writes:

gc> However, on MS-DOS and MS-Windows the value of SHELL in the
gc> environment is used, since on those systems most users do not
gc> set this variable, and therefore it is most likely set
gc> specifically to be used by make.

OK. Well, that's why I said "under UNIX this is true, but I don't know
about Windows" :).

Looks like we'll have to examine the code to see how SHELL is handled on
Windows/DOS platforms.

Paul D. Smith Find some GNU make tips at:
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Make-w32 mailing list

Do you Yahoo!?
Yahoo! News - Today's headlines
reply via email to

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