[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Make on XP - shell selection?
From: |
grischka |
Subject: |
Re: Make on XP - shell selection? |
Date: |
Sat, 20 Oct 2007 17:08:38 +0200 |
Eli Zaretskii wrote:
> I always wonder why people feel a need to post such derogatory
> comments. Is there some kind of satisfaction in it?
What do you expect? That is the nature of feedback. If it's all
well it mostly wont happen.
> I'm not sure it should be documented: the Windows port just behaves
> the same as the Unix original.
Whereas I'm not shure anyone even knows how exactly SHELL behaves
on windows.
> Granted, the code in the Windows port that does the equivalent is more
> complicated, but the net effect, as far as user is concerned, is the
> same: sh.exe is used if it is available.
Net effects are pointless if they miss the inner logic that the user
can understand and build on such logic with own creativity.
For example:
$ type makefile
SHELL = test.bat
all : ; @echo "$(SHELL)"
$ gmake
"c:/tools/test.bat"
Obviously gmake resolves "test.bat" from my PATH which is wrong in
so far as no variable is supposed to change the value on its own.
Someone might want do:
ifeq "$(SHELL)" "test.bat"
Then, although SHELL now prints as "c:/tools/test.bat", gmake still
uses "cmd.exe" to run the 'echo' command. Unless someone happens to
have "sh.exe" in the PATH, in which case it uses actually "test.bat"
as shell.
That is obscure. And unneccessary, even on windows.
> > Certainly it conflicts with the general rule that for makefile
> > portability reasons the SHELL to be used shall not depend on
> > individual environment settings.
> The OP's report was not about SHELL in the environment, it was about
> setting SHELL in the Makefile. Certainly, you won't claim that Make
> ignores _that_ on Unix, would you?
No, did I?
> And if by ``individual environment settings'' you mean the value of
> PATH,
Yes, that is what I mean ...
> then I don't see how Make can do better, since, unlike on Posix
> platforms, there's no "/bin" directory on your garden-variety Windows
> box. So it looks along PATH, which is a reasonable thing to do, IMO.
Not really. If it's only to find "sh(.exe)" in the PATH instead of in
"/bin" then it suffices to strip "/bin/" because then the OS can find
it on it's own. Which makes sense of course, no matter.
--- grischka