|
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
endif
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,
Rob
"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:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Make-w32 mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/make-w32
[Prev in Thread] | Current Thread | [Next in Thread] |