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
