Re: bsd.lib.mk question

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Jun 07, 2011 at 04:49:36PM +0100, Iain Hibbert wrote:
 > > a b:
 > >    echo foo > a
 > >    echo foo > b
 > >
 > > So, the question is: is it right to expect that this works?
 > 
 > no
 > 
 > That rule is not saying what you expect. It does not say that to make both
 > "a" and "b" you should follow these instructions, it says that to make
 > either of "a" or "b" you should follow these instructions..

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

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.

-- 
David A. Holland
dholland%netbsd.org@localhost