Date: Sun, 20 Aug 2000 07:55:20 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: Brian Fundakowski Feldman <green@FreeBSD.org>, "Andrey A. Chernov" <ache@nagual.pp.ru>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/make Makefile config.h job.c main.c Message-ID: <Pine.BSF.4.21.0008200721250.255-100000@besplex.bde.org> In-Reply-To: <399ED1DB.9AD397BC@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 19 Aug 2000, Marcel Moolenaar wrote:
> Brian Fundakowski Feldman wrote:
> >
> > On Sat, 19 Aug 2000, Marcel Moolenaar wrote:
> >
> > > I can't say I like the change. We use MAKE_SHELL={"csh", "sh", "ksh"} in
I agree.
> > This isn't meant to be a run-time conditional.
>
> I know.
I didn't think it would be that broken :-). Actually using the compile-time
conditional gives you a nonstandard `make'. It's like changing the gcc
defaults to -O3. Don't report buildworld failures if you use it :-).
> > Building make(1) specially to change the default isn't wrong: if the user
> > is advanced enough to be changing make(1)'s default shell, it shouldn't
> > be taken lightly :)
>
> We have everything we need to achieve the same by doing it at run-time;
> except that things seem broken. Adding build-time options would be an
> optimization then.
They seem to be remarkably broken. A POSIX.2 draft specifies that make
shall support the SHELL variable, but our make doesn't. (SHELL has the
obviously correct semantics: if it is in the environment then it affects
everything, including make, but if it is a make variable it only affects
make.) The rationale says that the historical MAKESHELL feature was
omitted because it had the wrong semantics (it was an environment variable
that only affected make).
> > This isn't a fix for .SHELL.
>
> I know. That's the problem.
>
> > This is entirely different.
>
> I know. That's the problem.
I'm not sure if .SHELL has any advantages over SHELL. Anyway, SHELL should
be fixed first since it is standard. The fix may be as simple as setting
converting SHELL to the shell used by make using a .SHELL directive in
sys.mk. sys.mk already has "SHELL ?= sh", but this doesn't do much, since
it doesn't affect the shell used by make. I commented it out in my version
about 6 years ago and haven't noticed any problems (there would only be
problems if makefiles used ${SHELL}). I did this as part of fixing the
%POSIX ifdefs in sys.mk (it is namespace pollution). I never finished this.
The %POSIX ifdefs never actually worked.
> > .SHELL does
> > not allow you to change the default shell nor the shell used to run
> > commands in some cases.
>
> According to the paper:
>
> .SHELL PMake is not constrained to only using the Bourne
> shell to execute the commands you put in the make-
> file. You can tell it some other shell to use with
> this target. Check out A Shell is a Shell is a
> Shell (section 4.4) for more information.
>
> Having a .SHELL in sys.mk that is controlled by make.conf will also be a
> way to set the default shell. And much easier than hacking code...
make.conf doesn't control sys.mk. It is a wart included at the end of
sys.mk. Thus it can set SHELL or .SHELL, but it can't cooperate with
sys.mk.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0008200721250.255-100000>