subdirs: unify rules for "cleaning" and "normal" recursive targets
authorStefano Lattarini <stefano.lattarini@gmail.com>
Sun, 10 Jun 2012 21:08:07 +0000 (23:08 +0200)
committerStefano Lattarini <stefano.lattarini@gmail.com>
Mon, 11 Jun 2012 15:03:23 +0000 (17:03 +0200)
commitec6a135799b9aa5da33130abeabad6fc8cd324b1
treea8d8f54d34ec06ca1a0c16d081edf73689bc9591
parentaf5d52b7862e2e49ae38b8060b6aa778f709d537
subdirs: unify rules for "cleaning" and "normal" recursive targets

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.

* NEWS: Update.
* 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.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
NEWS
lib/am/subdirs.am
t/list-of-tests.mk
t/subdir-distclean.sh [new file with mode: 0755]