Subsidiary SConscript
files make it easy to create a build
hierarchy because all of the file and directory names
in a subsidiary SConscript
files are interpreted
relative to the directory in which the SConscript
file lives.
Typically, this allows the SConscript
file containing the
instructions to build a target file
to live in the same directory as the source files
from which the target will be built,
making it easy to update how the software is built
whenever files are added or deleted
(or other changes are made).
For example, suppose we want to build two programs
prog1
and prog2
in two separate directories
with the same names as the programs.
One typical way to do this would be
with a top-level SConstruct
file like this:
SConscript(['prog1/SConscript', 'prog2/SConscript'])
And subsidiary SConscript
files that look like this:
env = Environment() env.Program('prog1', ['main.c', 'foo1.c', 'foo2.c'])
And this:
env = Environment() env.Program('prog2', ['main.c', 'bar1.c', 'bar2.c'])
Then, when we run SCons in the top-level directory, our build looks like:
% scons -Q
cc -o prog1/foo1.o -c prog1/foo1.c
cc -o prog1/foo2.o -c prog1/foo2.c
cc -o prog1/main.o -c prog1/main.c
cc -o prog1/prog1 prog1/main.o prog1/foo1.o prog1/foo2.o
cc -o prog2/bar1.o -c prog2/bar1.c
cc -o prog2/bar2.o -c prog2/bar2.c
cc -o prog2/main.o -c prog2/main.c
cc -o prog2/prog2 prog2/main.o prog2/bar1.o prog2/bar2.o
Notice the following:
First, you can have files with the same names
in multiple directories, like main.c in the above example.
Second, unlike standard recursive use of Make,
SCons stays in the top-level directory
(where the SConstruct
file lives)
and issues commands that use the path names
from the top-level directory to the
target and source files within the hierarchy.