Date: Sat, 19 Aug 2000 11:28:43 -0700 From: Marcel Moolenaar <marcel@cup.hp.com> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: "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: <399ED1DB.9AD397BC@cup.hp.com> References: <Pine.BSF.4.21.0008191351290.60744-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> > Makefile. This translates to DEFSHELL={0,1,2} in the sources, which is
> > ugly. At the same time we need to support the runtime ".SHELL". Looking
> > at the code now, I still see hardcoded shell names and hardcoded
> > special-handling based on build-time conditions instead of run-time
> > conditions.
>
> This isn't meant to be a run-time conditional.
I know.
> This is to set the default
> shell used.
I know.
> And there _needs_ to be special handling in some cases, like
> ENV must get unsetenv()ed for ksh or strange visual output is shown in
> -j builds.
This special-handling is also necessary if ksh has been selected with
the .SHELL target then, right? The point I'm trying to make is that
build-time behaviour is different from run-time behaviour WRT to
selecting a shell.
> 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.
> > Using MAKE_SHELL: csh doesn't seem to work and we don't have ksh in the
> > source tree. This basicly leaves only sh for us as a meaningful default.
> > I can't say we have a pressing need to have this functionality in the
> > first place.
>
> I have csh disabled because of course it's not going to work. It's in the
> make(1) code, though.
>
> And there is a perfectly good reason to have it, other than to
> just change the defaults. Changing shells can measurably increase
> performance (more than a few percent, around 10% for make world last I
> checked, and much more than that for ports builds).
>
> > I think that instead of fixing any problems, we introduced more. I'd
> > prefer this is backed out and work is started on real fixes. Anyone that
> > has ksh installed and want to use it can then use .SHELL. We can even
> > make that make.conf controlled, if people want it...
>
> This isn't a fix for .SHELL.
I know. That's the problem.
> This is entirely different.
I know. That's the problem.
> .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...
--
Marcel Moolenaar
mail: marcel@cup.hp.com / marcel@FreeBSD.org
tel: (408) 447-4222
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?399ED1DB.9AD397BC>