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.