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: Olly Betts
Subject: Re: Automatically Handling Tools that Produce Many Outputs
Date: Mon, 10 Dec 2007 21:51:58 +0000
User-agent: Mutt/1.5.9i

On Mon, Dec 10, 2007 at 09:15:26AM +0100, Ralf Wildenhues wrote:
> * 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:
> > > 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.

Thinking about this, my previous understanding of this could be summed
up as roughly "automake just copies stuff it doesn't understand from
input files to Makefile.in" rather than that verbatim copying is a
fundamental design goal.

> > 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>

Conditionals and "include" were those I had in mind (as well as "+="
which is mentioned there).

I just tried comparing some example files to see if there are other
such features and I noticed automake 1.10 makes seemingly arbitrary
changes to whitespace in some cases (e.g. blank lines between variable
definitions are removed or added, and "FOO = \" becomes "FOO =\").

> > > 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?

I can't think of a way to easily dig out statistically useful data
from a VCS or Google code search on how often it happens either to me or
generally.  But I mainly offered it as a more concrete example of the
sort of issues I had in mind.

Anyway, I have a partially formed idea for a way we might be able to
achieve this while allowing verbatim copying of make rules, and while
keeping single output and multiple output rules much more similar.
It's heavily inspried by Ralf's earlier two ideas.

It still suffers from the focus on the stamp file though, and there
are still bigger differences between single and multiple output rules
than I'd like.

The "unsafe" version is:

$(ELCFILES): $(ELFILES)
        for f in : $(ELFILES); do \
          test "$$f" != : || continue; \
          touch "$${f}c"; \
        done

Instead the user would write something like:

MULTITARGETS = elc-stamp

elc_stamp_TARGETS = $(ELCFILES)
elc-stamp: $(ELFILES)
        $(am__multitarget_begin)
        for f in : $(ELFILES); do \
          test "$$f" != : || continue; \
          touch "$${f}c"; \
        done
        $(am__multitarget_end)

And then automake would generate something equivalent to this extra code:

am__multitarget_begin = @rm -f address@hidden; touch address@hidden
am__multitarget_end = @mv -f address@hidden $@
am__make_many_locked = [...]

$(ELCFILES): elc-stamp
        @stamp=elc-stamp; $(am__make_many_locked)

EXTRA_DIST += <the dependencies of the stamp rule>
CLEANFILES += $(MULTITARGETS:=-lck) $(MULTITARGETS:=-t)

And for the "nodist_" case:

CLEANFILES += $(MULTITARGETS) $(elc_stamp_TARGETS)

Or for the "dist_" case:

EXTRA_DIST += $(MULTITARGETS) $(elc_stamp_TARGETS)
MAINTAINERCLEANFILES += $(MULTITARGETS) $(elc_stamp_TARGETS)

MULTITARGETS doesn't actually need to be explicitly specified, since it could
be determined by scanning rules which use $(am__multitarget_begin) and have a
matching xxx_TARGETS variable.  But that's perhaps less "automake-y"?

Also, I wonder if we could eliminate the need to specify $(am__multitarget_end)
by generating a "wrapper" rule which renames the lock.  I've not managed to
actually write a plausible version yet though.

Cheers,
    Olly




reply via email to

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