The source code for large software projects
rarely stays in a single directory,
but is nearly always divided into a
hierarchy of directories.
Organizing a large software build using SCons
involves creating a hierarchy of build scripts
which are connected together using the SConscript
function.
As we've already seen,
the build script at the top of the tree is called SConstruct
.
The top-level SConstruct
file can
use the SConscript
function to
include other subsidiary scripts in the build.
These subsidiary scripts can, in turn,
use the SConscript
function
to include still other scripts in the build.
By convention, these subsidiary scripts are usually
named SConscript
.
For example, a top-level SConstruct
file might
arrange for four subsidiary scripts to be included
in the build as follows:
SConscript( [ 'drivers/display/SConscript', 'drivers/mouse/SConscript', 'parser/SConscript', 'utilities/SConscript', ] )
In this case, the SConstruct
file
lists all of the SConscript
files in the build explicitly.
(Note, however, that not every directory in the tree
necessarily has an SConscript
file.)
Alternatively, the drivers
subdirectory might contain an intermediate
SConscript
file,
in which case the SConscript
call in
the top-level SConstruct
file
would look like:
SConscript(['drivers/SConscript', 'parser/SConscript', 'utilities/SConscript'])
And the subsidiary SConscript
file in the
drivers
subdirectory
would look like:
SConscript(['display/SConscript', 'mouse/SConscript'])
Whether you list all of the SConscript
files in the
top-level SConstruct
file,
or place a subsidiary SConscript
file in
intervening directories,
or use some mix of the two schemes,
is up to you and the needs of your software.