On Mon, Sep 03, 2018 at 12:14:45PM -0900, Philip Guenther wrote: > On Mon, Sep 3, 2018 at 5:23 AM Marc Espie <[email protected]> wrote: > > > Our make is perfectly happy generating several targets with one rule. > > > > The only thing we're actually missing wrt % is suffixes rules with > > multiple results. > > > > See any Makefile that generates .h and .c file from .y, for instance > > lib/libkeynote/Makefile > > > > a line like: > > > > k.tab.c k.tab.h: keynote.y keynote.h signature.h > > $(YACC.y) $(YACCFLAGS) ${.CURDIR}/keynote.y > > > > looks exactly like what you want. > > > > Classically, a rule like that doesn't mean one invocation will generate > both targets, but rather that the same recipe can be invoked for each > target (with different values for $@, etc). In default single-job mode (no > -jN) this works out fine as after the first invocation 'make' will notice > the second file is already up-to-date, but with -jN some makes could decide > to build both of the targets at the same time and invoke yacc twice, > possibly resulting in truncated/corrupted output files. > > Does our make have some logic in the -jN handling to detect and prevent > that, Marc?
Philip, is that a rhetorical question ? You know quite well it does. There's code that looks at the target line for presence of $@, to desambiguate multiple targets rules from "macro-like" behavior, and the other targets get locked out while one target is built, so that in effect all targets get updated at once. Oh, and it's documented in the man page.... RTFM. It was actually somebody from NetBSD (not remembering who) who pointed out that make extended description in POSIX changed at some point to actually allow for sane behavior wrt multiple targets. > Otherwise, the workaround has been as Geoff noted: have all the target > files depend on a timestamp file which has the real recipe and > prerequisites. That's still recommended for GNU make users when there's no > reasonable set of patterns that can match the generated files. People > occasionally pine for the SunOS 4.x 'make' feature of "targ1 + targ2 [+ > targN...]" functionality, but it's not a great syntax and no one has done > the work. I used to think so before the above changes were pointed out to me.
