Re: Static multiple target rules

[tom honermann]

On 3/2/2010 2:45 AM, Edward Welbourne wrote:
> > I've been struggling for some time now with how to write rules for 
> > commands that generate multiple targets
> >     
>
> A familiar and annoying problem: make really believes in commands that
> generate just one (relevant) file, and doesn't fit so well with ones
> that generate several.
>   
And yet, pattern rules do have such support.  I'd love to see a syntax 
added to enable static
multiple target rules.  Since parenthesis are already treated specially 
in target names (for archive
rules), perhaps a syntax like the following could be used without 
harming backward compatibility.

   (y.tab.h y.tab.c y.output): grammar.y
       yacc -d -v $^

> > The next thing to try is using a proxy or timestamp file:
> >
> >    yacc.ts: grammar.y
> >        yacc -d -v $^
> >        touch $@
> >
> >    y.tab.h y.tab.c y.output: yacc.ts
> >     
>
> A quarter of an hour after reading your mail, I had a mildly perverted
> idea: instead of a touch-file, use a tar-file !  The problem you point
> to is when the touch file exists but the files we want don't: we need
> a command for the rule that declares their dependency on it; and that
> command needs to be able to generate the outputs from the fake file.
>
>     yacc.ts: grammar.y
>         yacc -d -v $^
>         tar cf $@ y.tab.h y.tab.c y.output
>
>     y.tab.h y.tab.c y.output: yacc.ts
>         tar xf $< -m $@
>
> Note the crucial -m in the extracting tar, so that we touch the
> outputs after the tar-file has been created, thereby avoiding
> re-extracting every time we run make.
>
> Not sure how well that'd work but it *looks* like it should ... and it
> should generalise reasonably well.  Unfortunately I can't, just yet,
> see how to turn it into a pattern rule for general .y file processing,
>
>         Eddy.
>   
Nice idea!  I like this much better than the workaround I had used 
involving $(shell...) and removing
the time-stamp file.  The only downsides to this I see are:

1: The duplicate file storage.  Probably not a big deal.
2: The extra processing time to archive and extract the files.  Again, 
probably not a big deal.
3: The "why'd they do that?" questions coming from people unfamiliar 
with the technique.
4: It doesn't address that nagging feeling that make should be able to 
support this.

Tom.