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 [EMAIL PROTECTED]; touch [EMAIL PROTECTED] am__multitarget_end = @mv -f [EMAIL PROTECTED] $@ 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
