Re: [9fans] mk surprises me

[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?

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.