Re: [PATCH 2/2] subdirs: unify rules for "cleaning" and "normal" recursive targets

[Stefano Lattarini]

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