Sam Varshavchik writes: > Harlan Stenn writes: > > The problem I've had is that the info above does a great job of saying > > "recursive Make can be a problem" but I haven't found anything to help > > me make a useful non-recursive Make system. > > Non-recursive make systems can be a problem too. Anything can be a problem, > if it's not used properly. For any given tool there is a right way, and a > wrong way to use it. > > And once codebase crosses some threshold, having one, flat Makefile just > does not work. I count 81 Makefile.am's in gcc's svn tree. Even if someone > comes up with one flat Makefile to replace all of them, I'd be shocked if > the end result is unquestionably superior.
I'm not suggesting a single flat file for a non-recursive Makefile situation. I'm expecting there to be one Makefile in each directory. I'd also almost expect that the Makfile in each (build) directory would "call up" to the top-level Makefile with enough information to build the desired target. I'd also expect that the top-level Makefile would "source in" enough information from a file in each subdir (possibly not the Makefile) to figure out the entire dependency and build situation. H
