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::: 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. > 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 > Makefile.am 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. Cheers, Olly