From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] p9p mk issue 
In-reply-to: Your message of "Thu, 22 Nov 2007 14:48:43 EST."
	<20071122194833.1FE151E8C22@holo.morphisms.net> 
From: Bakul Shah <bakul+plan9@bitblocks.com>
Date: Fri, 30 Nov 2007 10:01:11 -0800
Message-Id: <20071130180111.68EB05B59@mail.bitblocks.com>
Topicbox-Message-UUID: 0f7b3e9c-ead3-11e9-9d60-3106f5b1d025

> That's not what I meant.  I meant that if you have
> complicated things like loops then you can put those
> recipes all in one file (that also contains MKSHELL=rc)
> and just include it.  Essentially all the Plan 9 mkfiles
> set HFILES, OFILES, TARG, and then include mkone,
> mkmany, and mksyslib.  Only those would possibly
> need to declare a MKSHELL.

Thanks for the clarification.  Yes that works for things like
running mk in subdir etc. but will require better abstraction
when one has code like

	for (a in ...)
		if (<some condition>)
			...

> P. S.  I realize it's suboptimal to have to set MKSHELL in each mkfile
> that uses rc-specific features, but it's the only way that scales.

To me what is suboptimal is that the default shell is
*different* on plan9 mk and p9p mk.  If ever p9p is ported to
Windows will you make cmd.com the default shell?  It
certainly does not have as much of a compatible subset with
rc as /bin/sh does.  The patch I supplied keeps mk behavior
exactly the same as now *unless* you set an env variable.
But I suspect we won't agree on this point!