automake
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]