Re: distclean should walk subdirs in reverse order

[Stefano Lattarini]

On 03/09/2013 04:09 PM, Sam Varshavchik wrote:
> Consider automake being used together with GNU make and autoconf.
> 
> Top level directory 'main'. Two subdirectories, 'a' and 'b'.
> 
> main/configure.ac
> 
> AC_CONFIGFILES([
> 
> ...
> 
> a/somefile.inc
> 
> ...
> 
> ])
> 
> main/Makefile.am:
> 
> SUBDIRS=a b
> 
> main/a/Makefile.am:
> 
> data_DATA=somefile.inc
> DISTCLEAN=somefile.inc
> 
> main/b/Makefile.am
> 
> include $(shell pwd)/../a/somefile.inc
> 
> main's configure creates a/somefile.inc frome somefile.inc.in, and
> main/b/Makefile will include it, since automake will refuse to parse
> such an include file, and leave it up to make to deal with. somefile.inc
> also gets installed (yes, I'm installing a makefile fragment, this is
> a development tool); and it also needs to be DISTCLEANed, for make
> distcheck to pass.
> 
> However, what's going to happen here is that distclean-recursive ends
> up recursing into main/a first, and remove somefile.inc, and failing
> when it subsequently recurses into main/b, since the included file
> isn't there any more.
> 
> I think that distclean-recursive should handle SUBDIRS or DIST_SUBDIRS
> in reverse order from what they're listed. Or, default to SUBDIRS in
> reverse order, or the explicit order given in DIST_SUBDIRS. In the
> meantime, off I go writing another convoluted gmake macro to set
> DIST_SUBDIRS by reversing SUBDIRS…
> 
My suggestion: if files in different subdirectories are actually
dependent on each other (that is, the subdirectories are not
really independent "modules" that can be built independently and
oblivious to each other), re-organize your build system to stop
using makefile recursion.  For more background and rationales, see
Peter Miller's excellent paper "Recursive Make Considered Harmful":
<http://aegis.sourceforge.net/auug97.pdf>

See also the old similar issue:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12064>

(Sorry for the overly curt reply, but time is what it is these
days).

HTH,
  Stefano