automake/24: distclean must sometimes be depth-first

[Tom Tromey <tromey at cygnus dot com>]

>Number:         24
>Category:       automake
>Synopsis:       distclean must sometimes be depth-first
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tromey
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 07 17:11:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     Tom Tromey
>Release:        current cvs
>Organization:
>Environment:

>Description:
From Debian:

A Debian user has reported a problem with automake-1.4 when using
subdirectories.

The info pages state, under "Top level":

   By default, Automake generates `Makefiles' which work depth-first
   (`postfix').

However, in a distclean-recursive, as well as other recursive cleans,
the top-level directory is handled first.

In the example which caused problems, in a package called timidity,
common.makefile.in is in the top-level directory.  When configure is
run, common.makefile is created in the top-level directory.  This file
is included in each Makefile.am (and the corresponding Makefile).

When "make distclean" is run, it first cleans the top-level directory,
when removes common.makefile.  Then make enters the subdirectories.
However, each Makefile in a subdirectory requires common.makefile
which has already been removed.  "make distclean" fails.

Included below is a fix for this problem, provided by Martin Mitchell
<martin@debian.org>.  This fix forces distclean to be depth-first, as
the documentation describes.

--- subdirs.am.orig     Sat Jun 12 11:38:33 1999
+++ subdirs.am  Sat Jun 12 11:38:51 1999
@@ -62,7 +62,7 @@
          test "$$subdir" = "." && dot_seen=yes; \
        done; \
 ## If we haven't seen `.', then add it at the beginning.
-       test "$$dot_seen" = "no" && rev=". $$rev"; \
+       test "$$dot_seen" = "no" && rev="$$rev ."; \
        target=`echo $@ | sed s/-recursive//`; \
        for subdir in $$rev; do \
          echo "Making $$target in $$subdir"; \


(Unfortunately I'm not certain this is always correct.
Sometimes we probably really do want to run clean rules
in reverse order.  Suppose that something in . depends
on something in a subdir.  An unlikely scenario?)
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: