[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending gmake to make it less dependant on the shell
From: |
Eli Zaretskii |
Subject: |
Re: Extending gmake to make it less dependant on the shell |
Date: |
25 Mar 2004 08:12:10 +0200 |
> Date: Wed, 24 Mar 2004 17:20:48 -0500
> From: "Paul D. Smith" <address@hidden>
>
> Well, GNU make can use any interpreter as a shell. If you don't like
> the problems with a Bourne-like shell you can always use Perl or some
> other portable interpreter, and write your rules in that language...
That's true, but IIRC, the criteria for invoking the shell (the list
of commands known to be shell built-ins, and special characters that
appear in the rule's command line) are slated towards the system shell
(sh or csh on Posix platforms, COMMAND and CMD on DOS/Windows). So
I'm not sure that using "SHELL = /usr/local/bin/perl" will indeed work
as well as "SHELL = /bin/sh". Am I missing something?
Btw, even setting SHELL in a Makefile causes a portability problem to
raise its ugly head: Posix platforms require the value of SHELL to be
a full path to the shell's executable, whereas on Windows it is
almost impossible to use such a full path, since there's no universal
standard for where programs are installed that one could rely upon.
So something like
SHELL = $(searchpath perl)
or maybe even a more general
SHELL = $(find perl,$PATH)
would already be a great relief for people who use GNU Make to build a
package on several different platforms. (Currently, as you, Paul,
know only too well, there are lots of ugly hacks in Make to cause it
to search along the PATH for a shell's executable on DOS and Windows.)