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>