Re: bsd.lib.mk question

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

On Tue, Jun 07, 2011 at 06:23:21PM +0100, David Laight wrote:
 > 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
 > ':'!)

"I had to fix SVR4 make" is not the sign of a portable or viable
construct :-)

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

No, traditionally the same syntax explicitly serves both purposes. The
AND behavior used to be explicitly documented in the gmake manual, and
it certainly used to be part of the make lore.

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

I'd question that, unless you mean specifically in our build system
(where it can be changed easily enough) because of the portability
issues I already mentioned.

Also, calling it OR behavior is not really correct. The point isn't
that it creates one OR the other target depending on recipe logic make
can't interpret. It's more of a FOR behavior in the sense that it
creates an implicit loop over the left-hand-side targets.

We have explicit for loops, so we don't really need implicit ones. The
only reason to preserve this behavior would be for compatibility with
legacy make and legacy makefiles, but as the construct doesn't really
work in legacy make that doesn't seem like a major issue.

(And also, see the bottom of this mail.)

 > 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

...yes, until you try to set up a distributed build system and
discover that foo.yac.c doesn't come back from the remote build host
because it's not declared in the makefile. Or whatever.

There's really no reason not to do this right.


...also, I just thought of a sleazy way to make it work for both
cases: treat it as AND for graph purposes but set $(.TARGET) to the
first of the list of targets that's out of date relative to the
sources. Then if the makefile writer meant OR make will end up
invoking the recipe repeatedly with $(.TARGET) set to each target in
succession, at the (relatively minor) cost of not being able to
parallelize those targets.

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