> 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!
