Re: Recursive Make Considered Harmful

[gk]

At 02:21 PM 10/24/2002 -0700, gk wrote:
> I see no value for sub-make except in the case where a system already uses 
> it and you don't want to bother changing things because they aren't broken 
> (yet).

I have changed my opinion. I think there is a very clear divide between 
when recursion is helpful and harmful. See if you agree.

* calling $(MAKE) serially, in a for loop, is generally bad because you 
can't take advantage of concurrent jobs (see discussion on phony targets in 
the Gnu make manual).
* primary advantage of recursive make is concurrent jobs;
        secondary advantage: make won't exit if errors encountered in one 
branch
* primary disadvantage of recursive make is that prerequisites may be 
missing or the build order might be wrong
        secondary disadvantage: higher maintenance costs

THERFORE: any target THAT WILL NEVER HAVE PREREQUISITES (phony targets 
especially) can use recursion without risk!

For example, 'clean' is an ideal candidate for recursion.

I am working on this strategy:

* PROJECT_MAKEFILE
- the TOP level, controlling makefile: includes all pattern rules and other 
global stuff
- this is always the active makefile invoked when calling make from any 
directory:
        make -f $PROJECT_MAKEFILE <options> <targets>
- includes the DIRECTORY_MAKEFILE in the top project directory
- includes COMMON_INCLUDED_MAKEFILE  in the top project directory

* COMMON_INCLUDED_MAKEFILE
- contains ONLY targets like 'clean' with NO PREREQUISITES
- included by every DIRECTORY_MAKEFILE
- wrapped in ifndef __COMMON_INCLUDED_MAKEFILE  ... to avoid infinite 
include loop

* DIRECTORY_MAKEFILE
- auto-generated; one per directory
- includes COMMON_INCLUDED_MAKEFILE
- includes every DIRECTORY_MAKEFILE (auto-generated) in immediate 
subdirectories (only one-level deep)
- includes every DEPENDENCY_MAKEFILE in the directory

* DEPENDENCY_MAKEFILE
- auto-generated; one per source file
- defines prerequisites of all targets that related to a given source file

- Greg Keraunen <address@hidden>