[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatically Handling Tools that Produce Many Outputs
From: |
Ralf Wildenhues |
Subject: |
Re: Automatically Handling Tools that Produce Many Outputs |
Date: |
Mon, 10 Dec 2007 09:15:26 +0100 |
User-agent: |
Mutt/1.5.17 (2007-11-13) |
Hello Olly,
* Olly Betts wrote on Sun, Dec 09, 2007 at 03:53:11AM CET:
> On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> > * Olly Betts wrote on Tue, Nov 27, 2007 at 01:30:31AM CET:
>
> > > data.c data.h::: data.foo
> > > foo data.foo
> >
> > Yuck. Let's better not overload `make' syntax. That would drive us
> > further away from being able to copy the contents of Makefile.am into
> > the output file, which is one Automake design item.
>
> I wasn't aware of that. It does seem to be violated by several very
> useful automake features.
Which features are you thinking of that violate this but are not listed
in these chapters of the manual?
<http://sources.redhat.com/automake/automake.html#General-Operation>
<http://sources.redhat.com/automake/automake.html#Extending>
We should add them to the `Extending' chapter. Actually, I think we
should add the += feature to that chapter, too.
> > MULTITARGETS = elc-stamp
> > elc_stamp_TARGETS = $(ELCFILES)
> > elc_stamp_SOURCES = $(ELFILES)
> > elc_stamp_COMMAND = \
> > for f in : $(elc_stamp_SOURCES); do \
> > test "$$f" != : || continue; \
> > touch "$${f}c"; \
> > done
>
> The big downside of this approach is that a multiple output rule looks
> totally different to a normal make rule. That requires extra mental
> effort when writing, reading, and maintaining build systems.
Yes, good point.
> In particular, it would be a pain to add outputs to a single output
> rule, or reduce a multiple output rule to a single output one.
Is that something that happens often?
Cheers,
Ralf