At Monday 02 August 2010, Ralf Wildenhues wrote: > Hi Stefano, > > * Stefano Lattarini wrote on Mon, Aug 02, 2010 at 12:10:10PM CEST: > > At Sunday 01 August 2010, Ralf Wildenhues wrote: > > > So, here's the deal: currently, Automake has > > > > > > RECURSIVE_TARGETS > > > RECURSIVE_CLEAN_TARGETS > > > AM_RECURSIVE_TARGETS > > > > Is there any good reason (apart from naybe > > backward-compatibility) for keeping these as three separate > > variables? > > Well, yes. clean targets need to a different subdir traversal > order, and currently, the latter lists more than the sum of the > former: it also lists targets that invoke `make' recursively > within the same directory. The latter is needed in some cases > (mostly for hidden dependencies), and listing them is needed in > order to avoid unwanted parallel execution; writing a section > about this necessity has been on my todo list for a while: the > deal is that you should not run make -jN T1 T2 > > if both T1 and T2 are listed in $(AM_RECURSIVE_TARGETS). OK, thanks for the explanation.
> And yes, backward compatibility is very important, too. I've > checked codesearch now, these variables are used elsewhere > already. :-/ > Well, that was somewhat predictable, since the names of these variables seem to suggest that they're not internal variables. Maybe it would be a good idea to go on with renamings: RECURSIVE_TARGETS => am__RECURSIVE_TARGETS ... RECURSIVE_CLEAN_TARGETS => am__RECURSIVE_CLEAN_TARGETS AM_RECURSIVE_TARGETS => am__AM_RECURSIVE_TARGETS and deprecate the old RECURSIVE_TARGETS etc. names (while still retaining them for, say, a couple of years). WDYT? > > > > > 1) What to name them? > > > > > > RECURSIVE_USER_TARGETS > > > RECURSIVE_USER_CLEAN_TARGETS > > > ALL_RECURSIVE_USER_TARGETS > > > > What about `EXTRA_RECURSIVE_TARGETS' etc. instead? > > Ah, that's a good idea; thanks. > > > Also, I'd like to have a way to specify a recursive targers which > > should recurse in a limited set of a projects' subdirectories, > > and not in all of $(SUBDIRS). Do you think this would be > > possible/worthwhile? > > Can you give an example what this would be good for? Yes, I'd like to be able to do what proposed in this old patch series of mine: <http://www.mail-archive.com/automake-patc...@gnu.org/msg01848.html> without having to recurse to ugly cut-and-paste from lib/am/subdirs.am internals, like this: ## Factor out non-obvious shell code common to different targets. recurse_in_subdirs_cmd = \ fail= failcom='exit 1'; \ for f in x $$MAKEFLAGS; do \ case $$f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ for subdir in $$subdirs; do \ (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $@) || eval $$failcom; \ done; \ test -z "$$fail" The same holds for e.g. the `recheck' target provided in the top-level Automake's own Makefile.am, where we again can see cut-and-paste from (old and buggy!) lib/am/subdirs.am internals: .PHONY: recheck recheck: @failcom='exit 1'; \ for f in x $$MAKEFLAGS; do \ case $$f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ for subdir in $(TEST_SUBDIRS); do \ (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $@) || eval $$failcom; \ done; \ test -z "$$fail" > My idea was > that if the user adds a recursive target but then doesn't specify > an *-am rule in some directory, that the rule would just traverse > that directory without doing anything by default. But would it still recurse in that directory's subdirectories? If yes, everything's fine with your approach (even if we could then IMHO find a better naming than `*-am' for recusrive rules, but this is a minor point). Otherwise, if I wanted a recursive target `foo' descending in say, bar/tests/ and baz/quux/tests/, it would still be necessary for me to add dummy `foo-am' (or `foo'?) targets to bar/Makefile.am, baz/Makefile.am and baz/quux/Makefile.am, and a dummy dependency like `foo-am: foo' to bar/tests/Makefile.am and baz/quux/tests/Makefile.am. > So your suggestion would be optimization only, right? Not exactly; I just wanted to make it easier for the maintainer to write recursive rules without adding too much boilerplate code. I don't mind an extra recursion here and there (which the current automake already does quite often, BTW). Have I managed to make my point clear this time? Thanks, Stefano
