Re: bsd.lib.mk question

["Simon J. Gerraty" <sjg%juniper.net@localhost>]

dholland writes:
>> =A0> You could simply add a touch to parser.c so that it is always newer =
>that
>> =A0> parser.h
>>
>> Yes, I suppose that would work but it's still gross.

Simple and effective.
The following may be gross, but it "just works" with -j:

.y.h:
        yacc -d ${.IMPSRC}
        mv y.tab.h ${.PREFIX}.h
        mv y.tab.c ${.PREFIX}.c
        touch ${.PREFIX}.c

.y.c:   ${.TARGET:R:T}.h
        true

you could also cp y.tab.c ${.PREFIX}.c (to ensure the .c is newer)
but the touch is more explicit and the mv disposes of y.tab.c

>> It's the responsibility of make to be expressive enough allow you to
>> state what you mean and not have to resort to semantic workarounds.

Make may be deficient but its the tool we have.
Lots of people have tried to do "better", 
I expect to be using make for a while yet ;-)

uebayasi writes:
>Details can be hidden.  Is there any other problem?
>
>The only rule we have to remember is, "generate one file at one time".
> If some command violates this rule, you need a little care (apply a
>wrapper command).  Otherwise rules can be written simple.  No race, no
>side-effect, full parallel build.

There's no race in the example above either.
Nor is it difficult to follow.  
But as you say, these are corner cases.