[Top][All Lists]

[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: Sun, 9 Dec 2007 02:53:11 +0000
User-agent: Mutt/1.5.9i

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:
> > I don't have a concrete proposal, but it seems that this would need
> > to be controllable rather than automatically adjusting any rule with
> > multiple targets, if only to avoid messing with rules which are already
> > protected.
> Not sure what you mean here.  But surely rewriting rules is bad.

I didn't (and still don't) have a particular idea on the best approach
to take here, but one obvious approach which might work would be to just
automatically "fix" any rule with multiple targets.  One obvious
drawback of that is that multiple target rules which have been manually
made safe would still get this treatment.  That probably wouldn't break
them, but it wouldn't be pretty.

It's probably a bad approach for several other reasons anyway.

> >     data.c data.h:::
> >             foo
> Yuck.  Let's better not overload `make' syntax.  That would drive us
> further away from being able to copy the contents of 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.

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

But then I can't see how to avoid that without either violating the
verbatim-ish copying design principle, or writing even single target
rules in this way.

> FWIW, if I were you, for now I'd just define this
> (and automake would probably have an am__make_many_locked like this):
> [...]
> I would appreciate if you could test on your specific use case whether
> the above is general enough to be useful, and whether the resulting
> code looks too ugly for words or not.

First impressions: it's certainly an improvement on inserting the
locking boilerplate verbatim for each use, and it means most of the
locking mechanism is in a single place and so can be adjusted more
easily, which is definitely better.

I wouldn't say it's too ugly for words, but it feels rather clumsy
to me.  I'll try converting all the multiple output rules to using it
and see what I think then.


reply via email to

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