Re: rule w/multiple targets causes failure in -j mode; how to fix

[Jamie Cuesta]

Eric Melski wrote:

> You have two options:
>
> 1.  Use multi-output pattern rules to describe your
> targets.  This is the correct (and only) way to
> genuinely express "this one rule creates multiple outputs"
> in gmake.  For example:
>
> %.h %.o: %.c
>     @echo Building $*.o and $*.h from
> $<.
>     @touch $*.h
>     @touch $*.o
>
> The only drawback to this approach is that it requires that
> your outputs and the inputs share a common stem, which may
> or may not be possible in your case.

Does the sample pattern rule above not also apply to all .c files not "covered" 
by explicit rules?  If it does apply to all .c files, this is a drawback for 
me: I have a single .c file which follows this pattern, and hundreds which do 
not (they simply compile to .o w/o the .h-generation weirdness).  Being forced 
(due to this being the only "correct" solution) to use a pattern rule to 
express the exceptional (and filename-specific) case, and standard (explicit?) 
rules in the far more numerous "regular case" seems like a drawback.  

> 2.  Use a dummy target to actually do the work, then
> make both your .o and .h targets depend on that dummy:
>
> output.h output.o: generate_output
>
> generate_output: input.c
>     @echo Building output.o and output.h
> from input.c.
>     @touch output.h
>     @touch output.c
>
> This is a little clumsy, and it doesn't work so well with
> incremental builds, but it will at least protect you from
> collisions when doing a parallel build, because now there
> really is only one rule that updates both output files.

This seems like the only viable choice in my situation, so I want to clearly 
understand the problems with it.  Clumsiness: I suppose you say this because 
_two_ rules are needed just to make the original single-rule construct 
"-j-safe"?  Since my makefile is programmatically generated, this is not a 
problem (I add this pattern to my makefile-gen program, and it's taken care of 
forever).  That leaves "it doesn't work so well with incremental builds".  This 
I don't understand: I assume make will still operate correctly (if .c is newer 
than either of .h or .o, then run rule to rebuild both), so in what way does 
this construct "[not] work so well with incremental builds"?  Is it simply 
because internally make has to evaluate two rules instead of the more ideal 
one?  Or am I missing something... ?

Thanks so much for your insights,  Jamie