On 06/11/2012 12:58 AM, Stefano Lattarini wrote:
> Before this change, the recursive invocation of cleaning targets in
> the $(SUBDIRS) where done in inverse order, i.e., starting from the
> last $(SUBDIRS) entry and proceeding towards the first. According
> to the code comments, this was done ...
>
> ... in an attempt to alleviate a problem that can happen when
> dependencies are enabled. In this case, the .P file in one
> directory can depend on some automatically generated header
> in an earlier directory. Since the dependencies are required
> before any target is examined, make bombs.
>
> But this comment does not apply anymore to the current implementation
> of automatic dependency tracking: the '.Po' and '.Plo' files does not
> depend on any C header or source file, ever!
>
> So it seems that the distinction between "normal" and "cleaning"
> recursive targets is a stale leftover of an older implementation of
> the automatic dependency tracking. In fact, the Automake History
> manual seems to confirm this suspect; the section "First Take on
> Dependency Tracking" reads:
>
> Because each .P file was a dependency of Makefile, this meant
> that dependency tracking was done eagerly by make. For instance,
> "make clean" would cause all the dependency files to be updated,
> and then immediately removed. This eagerness also caused problems
> with some configurations; if a certain source file could not be
> compiled on a given architecture for some reason, dependency
> tracking would fail, aborting the entire build.
>
> and the following section "Dependencies As Side Effects" reads:
>
> In this approach, the .P files were included using the -include
> command, which let us create these files lazily. This avoided
> the "make clean" problem.
>
> So the distinction between "normal" and "cleaning" recursive targets
> has likely been obsolete since by then already. We can thus remove
> such distinction, thus reducing some complications and duplication in
> our rules. Doing so, the whole testsuite still passes (both with GCC
> and Sun C 5.9), even the test 'c-demo.sh', which, among the other
> things, exercise the setup described in the obsolete code comment
> referenced above.
>
> Finally, note that we still keep '$(RECURSIVE_CLEAN_TARGETS)' and
> '$(RECURSIVE_TARGETS)' as two distinct variables, to ensure a better
> backward-compatibility for any user-defined rules that happen to use
> those variables.
>
> * lib/am/subdirs.am ($(RECURSIVE_CLEAN_TARGETS), $(CLEAN_TARGETS)):
> Merge their recipes.
> * t/subdir-distclean.sh: New test, check that "./configure && make
> && make distclean" is actually a no-op, even when conditional SUBDIRS
> are involved.
> * t/list-of-tests.mk: Add it.
>
Gahhh, I had forgetten to add I proper NEWS entry! Fixed as follows:
diff --git a/NEWS b/NEWS
index 282fde2..bd6eb77 100644
--- a/NEWS
+++ b/NEWS
@@ -93,6 +93,16 @@ New in 1.12.2:
input file. Such a warning will also be present in the next
Autoconf version (2.70).
+* Cleaning rules:
+
+ - Recursive cleaning rules descends into the $(SUBDIRS) in the natural
+ order (as done by the other recursive rules), rather than in the
+ inverse order. They used to do that in order to work a round a
+ limitation in an older implementation of the automatic dependency
+ tracking support, but that limitation had been lifted years ago
+ already, when the automatic dependency tracking based on side-effects
+ of compilation had been introduced.
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.12.1:
Sorry for the noise,
Stefano
