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 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.