It's often useful to keep any built files completely
separate from the source files.
In SCons, this is usually done by creating one or more separate
variant directory trees
that are used to hold the built objects files, libraries,
and executable programs, etc.
for a specific flavor, or variant, of build.
SCons provides two ways to do this,
one through the SConscript function that we've already seen,
and the second through a more flexible
One historical note: the
used to be called
That name is still supported
but has been deprecated
because the SCons functionality
differs from the model of a "build directory"
implemented by other build systems like the GNU Autotools.
The most straightforward way to establish a variant directory tree
uses the fact that the usual way to
set up a build hierarchy is to have an
SConscript file in the source subdirectory.
If you then pass a
variant_dir argument to the
SConscript function call:
SCons will then build all of the files in the build subdirectory:
% ls src SConscript hello.c % scons -Q cc -o build/hello.o -c build/hello.c cc -o build/hello build/hello.o % ls build SConscript hello hello.c hello.o
But wait a minute--what's going on here? SCons created the object file build/hello.o in the build subdirectory, as expected. But even though our hello.c file lives in the src subdirectory, SCons has actually compiled a build/hello.c file to create the object file.
What's happened is that SCons has duplicated the hello.c file from the src subdirectory to the build subdirectory, and built the program from there. The next section explains why SCons does this.