[9fans] p9p mk issue

[9fans] p9p mk issue

[Bakul Shah]

Don't laugh but I am trying to use identical mkfiles on
FreeBSD & plan9 for some programs and it seems this is
impossible.

Consider a simple mkfile like this:

all:
	for (i in a b c)
		echo $i

9 mk fails with
Syntax error: Bad for loop variable
mk:    ...  : exit status=exit(2)

On rereading the p9p mk man page I discover MKSHELL.  So next
I add MKSHELL=... line at top of the above mkfile and now it
works.  Since I want most mkfiles to be portable, I add this
line in a mkfile included with < but it uses its own copy of
MKSHELL.  So then I tried

MKSHELL=$PLAN9/bin/rc 9 mk

but that doesn't help either.  Change mkfile to this now

MKSHELL=$PLAN9/bin/rc
FOO=fum
all:
	for (i in a b c)
		echo $i $MKSHELL $FOO

But echo shows "a sh fum" etc. which is rather surprising.

Rather than try this hard to please sh users, would it make
sense to just use rc?  After all this is *plan9* mk!  To be
nice mk can pay attention to MKSHELL env. variable but that's
about it.  Even as a non-unix-hater I'd be perfectly happy
with that!

-- bakul

Re: [9fans] p9p mk issue

[Pietro Gagliardi]

On Nov 20, 2007, at 4:01 PM, Bakul Shah wrote:

> Don't laugh but I am trying to use identical mkfiles on
> FreeBSD & plan9 for some programs and it seems this is
> impossible.
>
> Consider a simple mkfile like this:
>
> all:
> 	for (i in a b c)
> 		echo $i
>
> 9 mk fails with
> Syntax error: Bad for loop variable
> mk:    ...  : exit status=exit(2)
>
> On rereading the p9p mk man page I discover MKSHELL.  So next
> I add MKSHELL=... line at top of the above mkfile and now it
> works.  Since I want most mkfiles to be portable, I add this
> line in a mkfile included with < but it uses its own copy of
> MKSHELL.  So then I tried
>
> MKSHELL=$PLAN9/bin/rc 9 mk
>
> but that doesn't help either.  Change mkfile to this now
>
> MKSHELL=$PLAN9/bin/rc
> FOO=fum
> all:
> 	for (i in a b c)
> 		echo $i $MKSHELL $FOO
>
> But echo shows "a sh fum" etc. which is rather surprising.
>
> Rather than try this hard to please sh users, would it make
> sense to just use rc?  After all this is *plan9* mk!  To be
> nice mk can pay attention to MKSHELL env. variable but that's
> about it.  Even as a non-unix-hater I'd be perfectly happy
> with that!
>
> -- bakul

/sys/doc/mk.ps: read section 5 on variables. It might help :-)

Re: [9fans] p9p mk issue

[Pietro Gagliardi]

On Nov 20, 2007, at 4:01 PM, Bakul Shah wrote:

> Don't laugh but I am trying to use identical mkfiles on
> FreeBSD & plan9 for some programs and it seems this is
> impossible.
>
PS - In my version of hoc(1), which is pure ANSI C, I use a makefile  
for UNIX systems and an mkfile for Plan 9.

Re: [9fans] p9p mk issue

[Jeff Sickel]

On Nov 20, 2007, at 3:44 PM, Pietro Gagliardi wrote:

>
> On Nov 20, 2007, at 4:01 PM, Bakul Shah wrote:
>
>> Don't laugh but I am trying to use identical mkfiles on
>> FreeBSD & plan9 for some programs and it seems this is
>> impossible.
>>
> PS - In my version of hoc(1), which is pure ANSI C, I use a makefile  
> for UNIX systems and an mkfile for Plan 9.

you should be able to do some sort of magic like:

<!cat $PLAN9/$objtype/mkfile.$SYSNAME


though you may have to do a little tweaking to get environment set  
correctly

Re: [9fans] p9p mk issue

[Bakul Shah]

> 
> On Nov 20, 2007, at 3:44 PM, Pietro Gagliardi wrote:
> 
> >
> > On Nov 20, 2007, at 4:01 PM, Bakul Shah wrote:
> >
> >> Don't laugh but I am trying to use identical mkfiles on
> >> FreeBSD & plan9 for some programs and it seems this is
> >> impossible.
> >>
> > PS - In my version of hoc(1), which is pure ANSI C, I use a makefile  
> > for UNIX systems and an mkfile for Plan 9.
> 
> you should be able to do some sort of magic like:
> 
> <!cat $PLAN9/$objtype/mkfile.$SYSNAME

For now I just changed default MKSHELL to rc in src/cmd/mk.
What I was really arguing for was for simplifying MKSHELL
semantics or getting rid of it altogether since it only
exists in p9p mk.

Re: [9fans] p9p mk issue

[John Stalker]

> For now I just changed default MKSHELL to rc in src/cmd/mk.
> What I was really arguing for was for simplifying MKSHELL
> semantics or getting rid of it altogether since it only
> exists in p9p mk.

I would keep MKSHELL.  I use mk a lot under FreeBSD.  They're
mostly things I originally used bmake for, but I got annoyed
with various of its oddities.  Having MKSHELL=/bin/sh means
less work in converting Makefiles to mkfiles.  You can
always set MKSHELL=$PLAN9/bin/rc.  If I remember, your
original problem was in inheriting MKSHELL in recursive use.
Getting rid of MKSHELL seems like a drastic solution to
that problem.
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] p9p mk issue

[Russ Cox]

> >> Don't laugh but I am trying to use identical mkfiles on
> >> FreeBSD & plan9 for some programs and it seems this is
> >> impossible.
> 
> For now I just changed default MKSHELL to rc in src/cmd/mk.
> What I was really arguing for was for simplifying MKSHELL
> semantics or getting rid of it altogether since it only
> exists in p9p mk.

if you want to use rc in both places, then setting MKSHELL=rc is enough.
the plan 9 mk will ignore it.

MKSHELL is here to stay.  the unix versions of mk have 
traditionally used sh not rc, and there are users who
depend on that.  

also, while using sh by default is a little annoying,
it simplifies the plan9port build process considerably,
since rc doesn't have to get bootstrapped just to get
mk running.

russ

Re: [9fans] p9p mk issue

[Bakul Shah]

> > >> Don't laugh but I am trying to use identical mkfiles on
> > >> FreeBSD & plan9 for some programs and it seems this is
> > >> impossible.
> > 
> > For now I just changed default MKSHELL to rc in src/cmd/mk.
> > What I was really arguing for was for simplifying MKSHELL
> > semantics or getting rid of it altogether since it only
> > exists in p9p mk.
> 
> if you want to use rc in both places, then setting MKSHELL=rc is enough.
> the plan 9 mk will ignore it.

Yeah that is one solution except that pretty much every
mkfile will need this line and I hate having to litter
mkfiles.

> MKSHELL is here to stay.  the unix versions of mk have 
> traditionally used sh not rc, and there are users who
> depend on that.  
> 
> also, while using sh by default is a little annoying,
> it simplifies the plan9port build process considerably,
> since rc doesn't have to get bootstrapped just to get
> mk running.

OK, how about this?  If env. var MKSHELL is set to rc, then
set the default value of make variable MKSHELL to rc else to
sh.  You get exactly the same effect as now and I get what I
want by setting MKSHELL env. var to rc.

I just reran $PLAN9/INSTALL with this change and it works
like before (as expected).

diff -r 976b3130f4f8 src/cmd/mk/shell.c
--- a/src/cmd/mk/shell.c	Wed Nov 07 17:30:51 2007 -0500
+++ b/src/cmd/mk/shell.c	Wed Nov 21 09:38:50 2007 -0800
@@ -5,7 +5,7 @@ static Shell *shells[] = {
 	&shshell
 };
 
-Shell *shelldefault = &shshell;
+Shell *shelldefault;
 
 Shell *shellt;
 Word *shellcmd;
@@ -41,6 +41,10 @@ void
 void
 initshell(void)
 {
+	if(shelldefault == nil){
+		char* sh = getenv("MKSHELL");
+		shelldefault = sh && strcmp(sh, "rc") == 0? &rcshell : &shshell;
+	}
 	shellcmd = stow(shelldefault->name);
 	shellt = shelldefault;
 	setvar("MKSHELL", shellcmd);

Re: [9fans] p9p mk issue

[Pietro Gagliardi]

I think the thing we need to fix is that mk is ignoring an assignment  
if a system variable is already defined in the environment. However,  
this doesn't apply to normal variables:

	term% cat mkfile
	x=3
	default:V:
		echo $x
	term% mk
	echo 3
	3
	term% x=4 mk
	echo 3
	4
	term% ed - mkfile
	1d
	w
	q
	term% x=4 mk
	echo $x
	4
	term%

Re: [9fans] p9p mk issue

[Russ Cox]

> OK, how about this?  If env. var MKSHELL is set to rc, then
> set the default value of make variable MKSHELL to rc else to
> sh.  You get exactly the same effect as now and I get what I
> want by setting MKSHELL env. var to rc.

No.  The fact is that some mkfiles are written with rc
recipes and some with sh recipes.  Setting a global default
is going to break one or the other.  It is just not that hard
to write 

MKSHELL=rc

if you start using complicated rc constructs.  The vast
majority of recipes one writes in mkfiles tend to be 
valid sh and rc syntax anyway, so I would not expect
that you'd have to put that in many mkfiles.

Also, if you have lots of complicated scripts in all your
mkfiles, maybe you are missing a chance to refactor 
the complication into a single included mkfile that 
can have MKSHELL=rc in it.  Then you've only got one.

Russ

Re: [9fans] p9p mk issue

[Bakul Shah]

> Also, if you have lots of complicated scripts in all your
> mkfiles, maybe you are missing a chance to refactor 
> the complication into a single included mkfile that 
> can have MKSHELL=rc in it.  Then you've only got one.

That was the first thing I tried -- didn't I mention that in
my original email on this?  But setting MKSHELL in an
included file works for only that file and then we are back
to sh.

Try this and watch it fail:

echo MKSHELL=rc > mkshell
echo '
<mkshell
all:
	for (i in a b)
		echo $i
' > mkfile
mk

I didn't consider this behavior to be a bug because the man
page says

    Mkfiles included via < or <| (q.v.) see their own private
    copy of MKSHELL, which always starts set to sh .

But if you expect the above script to work, then consider
this email exchange a tortured bug report!

Actually I don't really care what change you make.  As long
as I can limit MKSHELL=rc to one file I am happy!

Thanks for all the great software and your patience responses.

Have a great tofurkey day!

Re: [9fans] p9p mk issue

[Martin Neubauer]

I think what Russ meant was to put all complicated stuff that uses rc syntax
into a separate file with MKSHELL=rc on top and include that in yor mkfiles
(cf. mkone/mkmany on Plan 9).

	Martin

Re: [9fans] p9p mk issue

[Russ Cox]

> That was the first thing I tried -- didn't I mention that in
> my original email on this?  But setting MKSHELL in an
> included file works for only that file and then we are back
> to sh.
> 
> Try this and watch it fail:
> 
> echo MKSHELL=rc > mkshell
> echo '
> <mkshell
> all:
> 	for (i in a b)
> 		echo $i
> ' > mkfile
> mk

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.

As another example, p9p goes farther than Plan 9 in this
respect and has a $PLAN9/src/mkdirs that contains
the typical loop over directories and defines not just
"all" but "clean" and "nuke" and the rest.  Clients just
define a variable and then include mkdirs:

	<$PLAN9/src/mkhdr

	LIBS=common
	PROGS=smtp alias fs ned q send marshal vf 

	# libs must be made first
	DIRS=$LIBS $PROGS

	<$PLAN9/src/mkdirs

If you were going to use rc syntax in mkdirs, then it would
be the only file that needs to say MKSHELL=rc.

Russ


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.

Re: [9fans] p9p mk issue

[Bakul Shah]

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

Re: [9fans] p9p mk issue

[Russ Cox]

> To me what is suboptimal is that the default shell is
> *different* on plan9 mk and p9p mk.  

Mk has run on Unix for a very long time,
much longer than p9p has existed, and its
default shell there has always been /bin/sh.
On Plan 9 the default has always been /bin/rc.
The p9p mk straddles both worlds.
Either choice of default would have bothered
some of mk's users.  

I'm sorry the one I picked bothers you.

Russ