Re: bsd.lib.mk question

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Jun 07, 2011 at 04:48:57PM +0000, David Holland wrote:
> 
> The problem is that historically this syntax has been used to
> explicitly mean both things. To make both work correctly, the syntax
> needs to be extended.
> 
> My vote would be to make this form mean "a AND b" and establish some
> different form for the "a OR b" mode, for several reasons.
> 
> Note first that the typical usage of the AND form is stuff like
> 
>    foo.h foo.c: foo.y
>            yacc -d foo.y
> 
> whereas the typical usage of the OR form is stuff like
> 
>    $(OBJS): $(.TARGET:.o=.c)
>            gcc -c $<

Also:
    $(OBJS): $(HDRS) $${@:.o=.c}
             cc -o $@ ${@:.o=.c}
(Although I did have to fix SVR4 make to not error suffix translations on 
dynamic
dependencies - it didn't like the second ':'!)
 
> The first kind of rule is fully portable to (and from) traditional
> make, whereas the latter is frequently not -- in traditional make you
> can write rules like this as long as they use only $@ in the recipe,
> such as "$(DIRS):; mkdir $@", but to the best of my knowledge
> computing the RHS of the dependency based on the LHS has only ever
> worked in BSD make. That's reason #1.
> 
> Reason #2: most rules of the second form can at essentially zero cost
> be rewritten as
> 
>    .for O in $(OBJS)
>    $(O): $(O:.o=.c)
>            gcc -c $(O:.o=.c)
>    .endfor
> 
> whereas there is no simple rewrite for the AND form. So there may not
> even be any real need for a new syntax, and even if there is, many
> cases can be rewritten to maximize compatibility by not using it.
> 
> Reason #3, and perhaps most important: if the traditional syntax gets
> the AND interpretation, usages that intended the OR form will fail up
> front: things won't be created and builds will fail more or less
> promptly and deterministically. However, the other way around (as
> we're seeing right now) you get difficult to diagnose race conditions
> that once in a long while cause bizarre behavior.

I believe that the 'traditional' syntax is the OR one, ie (as in netbsd's
make and gmake):
    foo bar: dependencies
            commands
is shorthand for:
    foo: dependencies
            commands
    bar: dependencies
            commands

The fact that the command only get run once when they generate both files
is a side effect of the internal workings.

In any case what you call the 'OR' behaviour is much more common.

The 'yacc' problem can (sort of) be solved by:

foo.h:  foo.y
        # generate foo.h and foo.yac.c

foo.c: foo.h
        cp foo.yac.c $@

Which works unless some heathen deletes foo.yac.c but leaves foo.h

        David

-- 
David Laight: david%l8s.co.uk@localhost