What do you call a large project? For our purposes, it is one that requires a team of developers, may run on multiple architectures, and may have several field releases that require maintenance. Of course, not all of these are required to call a project large. A million lines of prerelease C++ on a single platform is still large. But software rarely stays prerelease forever. And if it is successful, someone will eventually ask for it on another platform. So most large software systems wind up looking very similar after awhile.
Large software projects are usually simplified by dividing them into major components, often collected into distinct programs, libraries, or both. These components are often stored under their own directories and managed by their own makefile s. One way to build an entire system of components employs a top-level makefile that invokes the makefile for each component in the proper order. This approach is called recursive make because the top-level makefile invokes make recursively on each component's makefile . Recursive make is a common technique for handling component-wise builds. An alternative suggested by Peter Miller in 1998 avoids many issues with recursive make by using a single makefile that includes information from each component directory. 
 Miller, P.A., Recursive Make Considered Harmful , AUUGN Journal of AUUG Inc., 19(1), pp. 14-25 (1998). Also available from http:// aegis . sourceforge .net/auug97.pdf.
Once a project gets beyond building its components, it eventually finds that there are larger organizational issues in managing builds. These include handling development on multiple versions of a project, supporting several platforms, providing efficient access to source and binaries, and performing automated builds. We will discuss these problems in the second half of this chapter.