Re: make: dealing with targets with multiple outputs

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

On Tue, Jun 11, 2019 at 09:26:17AM -0700, Simon J. Gerraty wrote:
 > >  > Ideally any solution should DTRT even with suffix rules.
 > > 
 > > There's no way to unless you want to invent a syntax for it or a way
 > > to graft additional stuff onto the left of a rule, which I don't think
 > > is a good idea.
 > 
 > This is why I suggested a special source.
 > 
 > foo.c foo.h: foo.y .NAMING_STUFF_IS_HARD
 > 
 > is all that is needed to mark foo.c foo.h as a set of related nodes
 > 
 > The actual rules used are unaffected.
 > The first listed node is the one we build, and expect the others to be
 > produced as side effect.

If you want a separate construction to tag things, it should be of the
form

.NAMING_STUFF_IS_HARD: foo.c foo.h

and not mixed up with other dependence information.

However, I don't think this is a good idea, because it becomes
unhooked from the recipe that's supposed to be shared among the
targets and means that you have to check for and reject makefiles like
this:

foo.o: foo.c foo.h
	$(CC) -DYES -c foo.c

bar.o: bar.c bar.h
	$(CC) -DNO -c bar.c

foo.o bar.o: .NAMING_STUFF_IS_HARD

It's much better to have it implicit in the construction of the
recipe, because then you (mostly) can't write down nonsensical forms.
(You can still probably do abusive things with multiple targets and
double-colon rules, but I'm not sure there's any need to care in
detail.)

 > > In general my recommendation remains to write
 > > 
 > >    .for S in $(SRCS:M*.y)
 > >    $(S:T:R).c $(S:T:R).h: $(S)
 > >            $(YACC) -d $(S) -o $(S:T:R).c
 > >            mv -f y.tab.h $(S:T:R).h
 > >    .endfor
 > >
 > > because (once the real problem we're talking about is finally fixed)
 > > that gives you exactly what it says, works when the sources are in
 > > another directory, and can easily be extended to work when the build
 > > products *also* go in another directory. None of that's true of suffix
 > 
 > Hmm I can't say I've noticed a problem with suffix rules working with
 > SRCS found via .PATH and products dropping in .OBJDIR

.OBJDIR is a horrible hack and shouldn't be used, and there are many
pitfalls with .PATH...

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