Re: [9fans] mk surprises me

Re: [9fans] mk surprises me

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] mk surprises me
> From: David Gordon Hogan <dhog@plan9.bell-labs.com>


> > the behaviour i expect (cp f1.c f1, even when f1.c was older than f1,
> > provided that hdr.h was younger than f1) is the one described in
> > plan9v2 documentation. admitedly your suspicion sounds much more
> > logical than the documenation.
> > i have (as well as i can) copied the contents of the mkfile from the book.
> > perhaps this is an error in the book? (there are others).
>
> I can not find your example in the documentation.  Could you
> please provide a reference?  (Name of paper and section name,
> please).

Plan9, The Documents.
Maintaining Files on Plan9 with Mk.
page 191.

This is Plan9 v2 (with Inferno around, making it possible to avoid C, I
never bought Plan9 v3).

...deleted
> Charles' diagnonis of the problem is correct, that
> you have effectively made f1.c depend on hdr.h, but not provided
> a recipe for making f1.c, hence if hdr.h is more recent than
> f1.c, mk complains.  The solution is to change the rule so that the
> source file f1.c doesn't depend on hdr.h.
>

this is fine. thank you.


bengt

Re: [9fans] mk surprises me

[David Gordon Hogan]

> the behaviour i expect (cp f1.c f1, even when f1.c was older than f1,
> provided that hdr.h was younger than f1) is the one described in
> plan9v2 documentation. admitedly your suspicion sounds much more
> logical than the documenation.
> i have (as well as i can) copied the contents of the mkfile from the book. 
> perhaps this is an error in the book? (there are others).

I can not find your example in the documentation.  Could you
please provide a reference?  (Name of paper and section name,
please).

I did find the following rule in an example:

	%.$O: hdr.h

but of course, this avoids the mistake of making _everything_
depend on hdr.h which your example contains.

> or, is there a difference between plan9 mk and inferno mk for host systems?

Not of this magnitude.  Your example should behave the same
way on both.  Charles' diagnonis of the problem is correct, that
you have effectively made f1.c depend on hdr.h, but not provided
a recipe for making f1.c, hence if hdr.h is more recent than
f1.c, mk complains.  The solution is to change the rule so that the
source file f1.c doesn't depend on hdr.h.

Re: [9fans] mk surprises me

[William Josephson]

On Thu, Mar 28, 2002 at 11:50:58AM +0100, Axel Belinfante wrote:

>  remade the first f1, which therefore was a quite a bit newer than
>  the hdr.h that I 'updated' using touch, to be one hour minus some
>  minutes older than the remade f1.
>  Essentially, the laptop multiboots plan 9, linux, windows98 and nt,
>  and I have not yet been able to get a 'stable' clock.

In my experience, this is invariable due to confusion over whether or
not the BIOS is storing time in GMT or the local TZ.  It used to be a
kernel configuration option for Linux, at least.  It is best to choose
the convention of the most recalcitrant system -- probably 98 or NT in
your case :-/

 -WJ

Re: [9fans] mk surprises me

[Axel Belinfante]

> ...deleted
> > I tried your example on plan 9 mk, and it seemed to work as expected.
> 
> just to check 'work as expected':
> the recipe was done (cp f1.c f1), even when f1.c was older than f1,
> provided that hdr.h was younger than f1?

Hmm. as it turned out, also my second message lacked a little coffee,
I'm very sorry for just having added to the confusion :-(

In retrospect, I think I got on the same results that you got (but did
not look/try far/hard enough to realise that). Repeating the experiment:

f1.c and hdr.h exist, no f1 yet: mk fc1: cp is done.
all exist, f1 newer than both f1.c and hdr.h: mk fc1: 'up to date'
touch hdr.h, so
all exist, f1 newer than f1.c but older than hdr.h: mk fc1: 'no recipe'

I tried also a variant of forsyth's solution, by just changing the
dependency fo hdr.h to be: 
   &: hdr.h
without changing the lines for the copy rule, I did get the expected
result (cp f1.c f1, even when f1.c was older than f1, provided that
hdr.h was younger than f1)

(while redoing the experiment, I got an interesting result that
 took me a while to figure out.
 I (re)booted a laptop to run the plan9 mk experiment.
 The laptop runs aux/timesync -rL . It looks like it shifted the
 clock back one hour (timezone related problem?) just after I had
 remade the first f1, which therefore was a quite a bit newer than
 the hdr.h that I 'updated' using touch, to be one hour minus some
 minutes older than the remade f1.
 Essentially, the laptop multiboots plan 9, linux, windows98 and nt,
 and I have not yet been able to get a 'stable' clock.
)

Sorry for the confusion,
Axel.

Re: [9fans] mk surprises me

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] mk surprises me
> From: forsyth@caldo.demon.co.uk


> >>% : hdr.h
> 
> i suspect that because you've said that everything depends on hdr.h, including 
f2.c,
> it decides it had better remake that too, since hdr.h has changed, but doesn't 
know how.

the behaviour i expect (cp f1.c f1, even when f1.c was older than f1,
provided that hdr.h was younger than f1) is the one described in
plan9v2 documentation. admitedly your suspicion sounds much more
logical than the documenation.
i have (as well as i can) copied the contents of the mkfile from the book. 
perhaps this is an error in the book? (there are others).
or, is there a difference between plan9 mk and inferno mk for host systems?

> try using & for this (similar to % but doesn't match . or /)
> 
> &: hdr.h
> 
> &: &.c
> 	cp $stem.c $target

thank you, & works as expected. unfortunatly i am not actually doing
anything with mk, just trying to figure out the documentation (which
uses % in this case).


bengt

Re: [9fans] mk surprises me

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> X-Authentication-Warning: copernicus.cs.utwente.nl: belinfan@localhost didn't 
use HELO protocol
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] mk surprises me
> From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
...deleted
> I tried your example on plan 9 mk, and it seemed to work as expected.

just to check 'work as expected':
the recipe was done (cp f1.c f1), even when f1.c was older than f1,
provided that hdr.h was younger than f1?


bengt

Re: [9fans] mk surprises me

[forsyth]

>>% : hdr.h

i suspect that because you've said that everything depends on hdr.h, including f2.c,
it decides it had better remake that too, since hdr.h has changed, but doesn't know how.

try using & for this (similar to % but doesn't match . or /)

&: hdr.h

&: &.c
	cp $stem.c $target

otherwise you could use regular expression rules

Re: [9fans] mk surprises me

[Axel Belinfante]

Ok, my previous response was widely off the mark,
 I guess, so, just to make up for it:

I tried your example on plan 9 mk, and it seemed to work as expected.
Now I'll step back for those more knowledgeable...
(and will have some more coffee)

Axel.

Re: [9fans] mk surprises me

[Axel Belinfante]

Someone more knowledgeable will surely correct me, if needed.
Don't you need to include one of the general mk 'rule templates'
(mkone, mkmany or such)? At least, that's what I recall seeing in
the plan 9 source tree, and in a similar way in the drawterm source.

Axel.

> mk does not do what i expect it to do. here are some facts:
> 
> 
> the mkfile
> 
> % : hdr.h
> 
> % : %.c
> 	cp $stem.c $target
> 
> 
> the files
> -rw-rw-r--   1 eleberg  avall          0 Mar 20 15:47 f2.c
> -rw-rw-r--   1 eleberg  avall          0 Mar 27 13:12 f2
> -rw-rw-r--   1 eleberg  avall          0 Mar 27 13:17 hdr.h
> 
> 
> the test
> ; inferno/Solaris/sparc/bin/mk -f mkfile f2
> mk: no recipe to make 'f2.c'
> 
> 
> according to my interpretation of 'maintaining files on plan9 with mk'
> (from plan9v2 documentation), page 188, the mkfile should produce f2
> from f2.c if hdr.h is younger then f2. but instead i get the error
> message above that i do not understand.
> is there anybody that sees where i go wrong?
> 
> possible sources of errors:
> i use mk from inferno, not plan9
> i have only the plan9v2 documentation, not v3 documentation.
> i am not very good with mkfiles
> 
> 
> bengt
> 

[9fans] mk surprises me

[Bengt Kleberg]

mk does not do what i expect it to do. here are some facts:


the mkfile

% : hdr.h

% : %.c
	cp $stem.c $target


the files
-rw-rw-r--   1 eleberg  avall          0 Mar 20 15:47 f2.c
-rw-rw-r--   1 eleberg  avall          0 Mar 27 13:12 f2
-rw-rw-r--   1 eleberg  avall          0 Mar 27 13:17 hdr.h


the test
; inferno/Solaris/sparc/bin/mk -f mkfile f2
mk: no recipe to make 'f2.c'


according to my interpretation of 'maintaining files on plan9 with mk'
(from plan9v2 documentation), page 188, the mkfile should produce f2
from f2.c if hdr.h is younger then f2. but instead i get the error
message above that i do not understand.
is there anybody that sees where i go wrong?

possible sources of errors:
i use mk from inferno, not plan9
i have only the plan9v2 documentation, not v3 documentation.
i am not very good with mkfiles


bengt