SCons 3.0.2

Because SCons is written in Python, you need to have Python installed on your system to use SCons. Before you try to install Python, you should check to see if Python is already available on your system by typing python -V (capital 'V') or python --version at your system's command-line prompt. For Linux/Unix/MacOS/BSD type systems this looks like:

$ python -V
Python 3.7.1
    

In a cmd shell or PowerShell on a Windows system (note PoweShell needs it spelled "python.exe" rather than "python"):

C:\>python -V
Python 3.7.1
    

If Python is not installed on your system, you will see an error message stating something like "command not found" (on UNIX or Linux) or "'python' is not recognized as an internal or external command, operable progam or batch file" (on Windows). In that case, you need to install Python before you can install SCons.

The standard location for information about downloading and installing Python is http://www.python.org/download/. See that page and associated links to get started.

For Linux systems, Python is almost certainly available as a supported package, possibly installed by default; this is often preferred to installing by other means, and is easier than installing from source code. Many such systems have separate packages for Python 2 and Python 3. Building from source may still be a useful option if you need a version that is not offered by the distribution you are using.

SCons will work with Python 2.7.x or with Python 3.5 or later. If you need to install Python and have a choice, we recommend using the most recent Python version available. Newer Pythons have significant improvements that help speed up the performance of SCons.

The canonical way to install SCons is from the Python Package Index (PyPi):

% python -m pip install scons
    

If you prefer not to install to the Python system location, or do not have privileges to do so, you can add a flag to install to a location specific to your own account:

% python -m pip install --user scons
    

SCons comes pre-packaged for installation on many Linux systems Check your package installation system to see if there is an SCons package available. Many people prefer to install distribution-native packages if available, as they provide a central point for management and updating. Some distributions have two SCons packages available, one which uses Python 2 and one which uses Python 3. If you need a specific version of SCons that is different from the package available, pip has a version option or you can follow the instructions in the next section.

If a pre-built SCons package is not available for your system, and installing using pip is not suitable, then you can still easily build and install SCons using the native Python distutils package.

The first step is to download either the scons-3.0.2.tar.gz or scons-3.0.2.zip, which are available from the SCons download page at http://www.scons.org/download.html.

Unpack the archive you downloaded, using a utility like tar on Linux or UNIX, or WinZip on Windows. This will create a directory called scons-3.0.2, usually in your local directory. Then change your working directory to that directory and install SCons by executing the following commands:

# cd scons-3.0.2
# python setup.py install
    

This will build SCons, install the scons script in the python which is used to run the setup.py's scripts directory (/usr/local/bin or C:\Python27\Scripts), and will install the SCons build engine in the corresponding library directory for the python used (/usr/local/lib/scons or C:\Python27\scons). Because these are system directories, you may need root (on Linux or UNIX) or Administrator (on Windows) privileges to install SCons like this.

# python setup.py install --version-lib
      

# python setup.py install --prefix=/opt/scons
      

$ python setup.py install --prefix=$HOME
      

Here's the famous "Hello, World!" program in C:

int
main()
{
    printf("Hello, world!\n");
}
   

And here's how to build it using SCons. Enter the following into a file named SConstruct:

Program('hello.c')
      

This minimal configuration file gives SCons two pieces of information: what you want to build (an executable program), and the input file from which you want it built (the hello.c file). Program is a builder_method, a Python call that tells SCons that you want to build an executable program.

That's it. Now run the scons command to build the program. On a POSIX-compliant system like Linux or UNIX, you'll see something like:

% scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cc -o hello.o -c hello.c
cc -o hello hello.o
scons: done building targets.

On a Windows system with the Microsoft Visual C++ compiler, you'll see something like:

C:\>scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
link /nologo /OUT:hello.exe hello.obj
embedManifestExeCheck(target, source, env)
scons: done building targets.

First, notice that you only need to specify the name of the source file, and that SCons correctly deduces the names of the object and executable files to be built from the base of the source file name.

Second, notice that the same input SConstruct file, without any changes, generates the correct output file names on both systems: hello.o and hello on POSIX systems, hello.obj and hello.exe on Windows systems. This is a simple example of how SCons makes it extremely easy to write portable software builds.

(Note that we won't provide duplicate side-by-side POSIX and Windows output for all of the examples in this guide; just keep in mind that, unless otherwise specified, any of the examples should work equally well on both types of systems.)

The Program builder method is only one of many builder methods that SCons provides to build different types of files. Another is the Object builder method, which tells SCons to build an object file from the specified source file:

Object('hello.c')
      

Now when you run the scons command to build the program, it will build just the hello.o object file on a POSIX system:

% scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cc -o hello.o -c hello.c
scons: done building targets.

And just the hello.obj object file on a Windows system (with the Microsoft Visual C++ compiler):

C:\>scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
scons: done building targets.

SCons also makes building with Java extremely easy. Unlike the Program and Object builder methods, however, the Java builder method requires that you specify the name of a destination directory in which you want the class files placed, followed by the source directory in which the .java files live:

Java('classes', 'src')
     

If the src directory contains a single hello.java file, then the output from running the scons command would look something like this (on a POSIX system):

% scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
javac -d classes -sourcepath src src/hello.java
scons: done building targets.

We'll cover Java builds in more detail, including building Java archive (.jar) and other types of file, in Chapter 26, Java Builds.

When using SCons, it is unnecessary to add special commands or target names to clean up after a build. Instead, you simply use the -c or --clean option when you invoke SCons, and SCons removes the appropriate built files. So if we build our example above and then invoke scons -c afterwards, the output on POSIX looks like:

% scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cc -o hello.o -c hello.c
cc -o hello hello.o
scons: done building targets.
% scons -c
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Cleaning targets ...
Removed hello.o
Removed hello
scons: done cleaning targets.

And the output on Windows looks like:

C:\>scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
link /nologo /OUT:hello.exe hello.obj
embedManifestExeCheck(target, source, env)
scons: done building targets.
C:\>scons -c
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Cleaning targets ...
Removed hello.obj
Removed hello.exe
scons: done cleaning targets.

Notice that SCons changes its output to tell you that it is Cleaning targets ... and done cleaning targets.

If you're used to build systems like Make you've already figured out that the SConstruct file is the SCons equivalent of a Makefile. That is, the SConstruct file is the input file that SCons reads to control the build.

# Arrange to build the "hello" program.
Program('hello.c')    # "hello.c" is the source file.
     

print("Calling Program('hello.c')")
Program('hello.c')
print("Calling Program('goodbye.c')")
Program('goodbye.c')
print("Finished calling Program()")
       

% scons
scons: Reading SConscript files ...
Calling Program('hello.c')
Calling Program('goodbye.c')
Finished calling Program()
scons: done reading SConscript files.
scons: Building targets ...
cc -o goodbye.o -c goodbye.c
cc -o goodbye goodbye.o
cc -o hello.o -c hello.c
cc -o hello hello.o
scons: done building targets.

You've already seen how SCons prints some messages about what it's doing, surrounding the actual commands used to build the software:

C:\>scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cl /Fohello.obj /c hello.c /nologo
link /nologo /OUT:hello.exe hello.obj
embedManifestExeCheck(target, source, env)
scons: done building targets.

These messages emphasize the order in which SCons does its work: all of the configuration files (generically referred to as SConscript files) are read and executed first, and only then are the target files built. Among other benefits, these messages help to distinguish between errors that occur while the configuration files are read, and errors that occur while targets are being built.

One drawback, of course, is that these messages clutter the output. Fortunately, they're easily disabled by using the -Q option when invoking SCons:

C:\>scons -Q
cl /Fohello.obj /c hello.c /nologo
link /nologo /OUT:hello.exe hello.obj
embedManifestExeCheck(target, source, env)

Because we want this User's Guide to focus on what SCons is actually doing, we're going to use the -Q option to remove these messages from the output of all the remaining examples in this Guide.

You've seen that when you call the Program builder method, it builds the resulting program with the same base name as the source file. That is, the following call to build an executable program from the hello.c source file will build an executable program named hello on POSIX systems, and an executable program named hello.exe on Windows systems:

Program('hello.c')
    

If you want to build a program with a different name than the base of the source file name, you simply put the target file name to the left of the source file name:

Program('new_hello', 'hello.c')
       

(SCons requires the target file name first, followed by the source file name, so that the order mimics that of an assignment statement in most programming languages, including Python: "program = source files".)

Now SCons will build an executable program named new_hello when run on a POSIX system:

% scons -Q
cc -o hello.o -c hello.c
cc -o new_hello hello.o

And SCons will build an executable program named new_hello.exe when run on a Windows system:

C:\>scons -Q
cl /Fohello.obj /c hello.c /nologo
link /nologo /OUT:new_hello.exe hello.obj
embedManifestExeCheck(target, source, env)

You've just seen how to configure SCons to compile a program from a single source file. It's more common, of course, that you'll need to build a program from many input source files, not just one. To do this, you need to put the source files in a Python list (enclosed in square brackets), like so:

Program(['prog.c', 'file1.c', 'file2.c'])
       

A build of the above example would look like:

% scons -Q
cc -o file1.o -c file1.c
cc -o file2.o -c file2.c
cc -o prog.o -c prog.c
cc -o prog prog.o file1.o file2.o

Notice that SCons deduces the output program name from the first source file specified in the list--that is, because the first source file was prog.c, SCons will name the resulting program prog (or prog.exe on a Windows system). If you want to specify a different program name, then (as we've seen in the previous section) you slide the list of source files over to the right to make room for the output program file name. (SCons puts the output file name to the left of the source file names so that the order mimics that of an assignment statement: "program = source files".) This makes our example:

Program('program', ['prog.c', 'file1.c', 'file2.c'])
       

On Linux, a build of this example would look like:

% scons -Q
cc -o file1.o -c file1.c
cc -o file2.o -c file2.c
cc -o prog.o -c prog.c
cc -o program prog.o file1.o file2.o

Or on Windows:

C:\>scons -Q
cl /Fofile1.obj /c file1.c /nologo
cl /Fofile2.obj /c file2.c /nologo
cl /Foprog.obj /c prog.c /nologo
link /nologo /OUT:program.exe prog.obj file1.obj file2.obj
embedManifestExeCheck(target, source, env)

You can also use the Glob function to find all files matching a certain template, using the standard shell pattern matching characters *, ? and [abc] to match any of a, b or c. [!abc] is also supported, to match any character except a, b or c. This makes many multi-source-file builds quite easy:

Program('program', Glob('*.c'))
    

The SCons man page has more details on using Glob with variant directories (see Chapter 16, Variant Builds, below) and repositories (see Chapter 22, Building From Code Repositories, below), excluding some files and returning strings rather than Nodes.

We've now shown you two ways to specify the source for a program, one with a list of files:

Program('hello', ['file1.c', 'file2.c'])
    

And one with a single file:

Program('hello', 'hello.c')
    

You could actually put a single file name in a list, too, which you might prefer just for the sake of consistency:

Program('hello', ['hello.c'])
    

SCons functions will accept a single file name in either form. In fact, internally, SCons treats all input as lists of files, but allows you to omit the square brackets to cut down a little on the typing when there's only a single file name.

# The following two calls both work correctly:
Program('program1', 'program1.c')
Program('program2', ['program2.c'])
    

common_sources = ['file1.c', 'file2.c']

# THE FOLLOWING IS INCORRECT AND GENERATES A PYTHON ERROR
# BECAUSE IT TRIES TO ADD A STRING TO A LIST:
Program('program1', common_sources + 'program1.c')

# The following works correctly, because it's adding two
# lists together to make another list.
Program('program2', common_sources + ['program2.c'])
    

One drawback to the use of a Python list for source files is that each file name must be enclosed in quotes (either single quotes or double quotes). This can get cumbersome and difficult to read when the list of file names is long. Fortunately, SCons and Python provide a number of ways to make sure that the SConstruct file stays easy to read.

To make long lists of file names easier to deal with, SCons provides a Split function that takes a quoted list of file names, with the names separated by spaces or other white-space characters, and turns it into a list of separate file names. Using the Split function turns the previous example into:

Program('program', Split('main.c file1.c file2.c'))
    

(If you're already familiar with Python, you'll have realized that this is similar to the split() method in the Python standard string module. Unlike the split() member function of strings, however, the Split function does not require a string as input and will wrap up a single non-string object in a list, or return its argument untouched if it's already a list. This comes in handy as a way to make sure arbitrary values can be passed to SCons functions without having to check the type of the variable by hand.)

Putting the call to the Split function inside the Program call can also be a little unwieldy. A more readable alternative is to assign the output from the Split call to a variable name, and then use the variable when calling the Program function:

src_files = Split('main.c file1.c file2.c')
Program('program', src_files)
    

Lastly, the Split function doesn't care how much white space separates the file names in the quoted string. This allows you to create lists of file names that span multiple lines, which often makes for easier editing:

src_files = Split("""main.c
                     file1.c
                     file2.c""")
Program('program', src_files)
    

(Note in this example that we used the Python "triple-quote" syntax, which allows a string to contain multiple lines. The three quotes can be either single or double quotes.)

SCons also allows you to identify the output file and input source files using Python keyword arguments. The output file is known as the target, and the source file(s) are known (logically enough) as the source. The Python syntax for this is:

src_files = Split('main.c file1.c file2.c')
Program(target = 'program', source = src_files)
    

Because the keywords explicitly identify what each argument is, you can actually reverse the order if you prefer:

src_files = Split('main.c file1.c file2.c')
Program(source = src_files, target = 'program')
    

Whether or not you choose to use keyword arguments to identify the target and source files, and the order in which you specify them when using keywords, are purely personal choices; SCons functions the same regardless.

In order to compile multiple programs within the same SConstruct file, simply call the Program method multiple times, once for each program you need to build:

Program('foo.c')
Program('bar', ['bar1.c', 'bar2.c'])
       

SCons would then build the programs as follows:

% scons -Q
cc -o bar1.o -c bar1.c
cc -o bar2.o -c bar2.c
cc -o bar bar1.o bar2.o
cc -o foo.o -c foo.c
cc -o foo foo.o

Notice that SCons does not necessarily build the programs in the same order in which you specify them in the SConstruct file. SCons does, however, recognize that the individual object files must be built before the resulting program can be built. We'll discuss this in greater detail in the "Dependencies" section, below.

It's common to re-use code by sharing source files between multiple programs. One way to do this is to create a library from the common source files, which can then be linked into resulting programs. (Creating libraries is discussed in Chapter 4, Building and Linking with Libraries, below.)

A more straightforward, but perhaps less convenient, way to share source files between multiple programs is simply to include the common files in the lists of source files for each program:

Program(Split('foo.c common1.c common2.c'))
Program('bar', Split('bar1.c bar2.c common1.c common2.c'))
       

SCons recognizes that the object files for the common1.c and common2.c source files each need to be built only once, even though the resulting object files are each linked in to both of the resulting executable programs:

% scons -Q
cc -o bar1.o -c bar1.c
cc -o bar2.o -c bar2.c
cc -o common1.o -c common1.c
cc -o common2.o -c common2.c
cc -o bar bar1.o bar2.o common1.o common2.o
cc -o foo.o -c foo.c
cc -o foo foo.o common1.o common2.o

If two or more programs share a lot of common source files, repeating the common files in the list for each program can be a maintenance problem when you need to change the list of common files. You can simplify this by creating a separate Python list to hold the common file names, and concatenating it with other lists using the Python + operator:

common = ['common1.c', 'common2.c']
foo_files = ['foo.c'] + common
bar_files = ['bar1.c', 'bar2.c'] + common
Program('foo', foo_files)
Program('bar', bar_files)
    

This is functionally equivalent to the previous example.

It is possible to override or add construction variables when calling a builder method by passing additional keyword arguments. These overridden or added variables will only be in effect when building the target, so they will not affect other parts of the build. For example, if you want to add additional libraries for just one program:

env.Program('hello', 'hello.c', LIBS=['gl', 'glut'])
    

or generate a shared library with a non-standard suffix:

env.SharedLibrary('word', 'word.cpp',
                  SHLIBSUFFIX='.ocx',
                  LIBSUFFIXES=['.ocx'])
    

It is also possible to use the parse_flags keyword argument in an override:

This example adds 'include' to $CPPPATH, 'EBUG' to $CPPDEFINES, and 'm' to $LIBS.

env = Program('hello', 'hello.c', parse_flags = '-Iinclude -DEBUG -lm')
    

Within the call to the builder action the environment is not cloned, instead an OverrideEnvironment() is created which is more light weight than a whole Environment()

You build your own libraries by specifying Library instead of Program:

Library('foo', ['f1.c', 'f2.c', 'f3.c'])
      

SCons uses the appropriate library prefix and suffix for your system. So on POSIX or Linux systems, the above example would build as follows (although ranlib may not be called on all systems):

% scons -Q
cc -o f1.o -c f1.c
cc -o f2.o -c f2.c
cc -o f3.o -c f3.c
ar rc libfoo.a f1.o f2.o f3.o
ranlib libfoo.a

On a Windows system, a build of the above example would look like:

C:\>scons -Q
cl /Fof1.obj /c f1.c /nologo
cl /Fof2.obj /c f2.c /nologo
cl /Fof3.obj /c f3.c /nologo
lib /nologo /OUT:foo.lib f1.obj f2.obj f3.obj

The rules for the target name of the library are similar to those for programs: if you don't explicitly specify a target library name, SCons will deduce one from the name of the first source file specified, and SCons will add an appropriate file prefix and suffix if you leave them off.

Library('foo', ['f1.c', 'f2.o', 'f3.c', 'f4.o'])
        

% scons -Q
cc -o f1.o -c f1.c
cc -o f3.o -c f3.c
ar rc libfoo.a f1.o f2.o f3.o f4.o
ranlib libfoo.a

StaticLibrary('foo', ['f1.c', 'f2.c', 'f3.c'])
        

SharedLibrary('foo', ['f1.c', 'f2.c', 'f3.c'])
        

% scons -Q
cc -o f1.os -c f1.c
cc -o f2.os -c f2.c
cc -o f3.os -c f3.c
cc -o libfoo.so -shared f1.os f2.os f3.os

C:\>scons -Q
cl /Fof1.obj /c f1.c /nologo
cl /Fof2.obj /c f2.c /nologo
cl /Fof3.obj /c f3.c /nologo
link /nologo /dll /out:foo.dll /implib:foo.lib f1.obj f2.obj f3.obj
RegServerFunc(target, source, env)
embedManifestDllCheck(target, source, env)

Usually, you build a library because you want to link it with one or more programs. You link libraries with a program by specifying the libraries in the $LIBS construction variable, and by specifying the directory in which the library will be found in the $LIBPATH construction variable:

Library('foo', ['f1.c', 'f2.c', 'f3.c'])
Program('prog.c', LIBS=['foo', 'bar'], LIBPATH='.')
      

Notice, of course, that you don't need to specify a library prefix (like lib) or suffix (like .a or .lib). SCons uses the correct prefix or suffix for the current system.

On a POSIX or Linux system, a build of the above example would look like:

% scons -Q
cc -o f1.o -c f1.c
cc -o f2.o -c f2.c
cc -o f3.o -c f3.c
ar rc libfoo.a f1.o f2.o f3.o
ranlib libfoo.a
cc -o prog.o -c prog.c
cc -o prog prog.o -L. -lfoo -lbar

On a Windows system, a build of the above example would look like:

C:\>scons -Q
cl /Fof1.obj /c f1.c /nologo
cl /Fof2.obj /c f2.c /nologo
cl /Fof3.obj /c f3.c /nologo
lib /nologo /OUT:foo.lib f1.obj f2.obj f3.obj
cl /Foprog.obj /c prog.c /nologo
link /nologo /OUT:prog.exe /LIBPATH:. foo.lib bar.lib prog.obj
embedManifestExeCheck(target, source, env)

As usual, notice that SCons has taken care of constructing the correct command lines to link with the specified library on each system.

Note also that, if you only have a single library to link with, you can specify the library name in single string, instead of a Python list, so that:

Program('prog.c', LIBS='foo', LIBPATH='.')
    

is equivalent to:

Program('prog.c', LIBS=['foo'], LIBPATH='.')
    

This is similar to the way that SCons handles either a string or a list to specify a single source file.

By default, the linker will only look in certain system-defined directories for libraries. SCons knows how to look for libraries in directories that you specify with the $LIBPATH construction variable. $LIBPATH consists of a list of directory names, like so:

Program('prog.c', LIBS = 'm',
                  LIBPATH = ['/usr/lib', '/usr/local/lib'])
      

Using a Python list is preferred because it's portable across systems. Alternatively, you could put all of the directory names in a single string, separated by the system-specific path separator character: a colon on POSIX systems:

LIBPATH = '/usr/lib:/usr/local/lib'
    

or a semi-colon on Windows systems:

LIBPATH = 'C:\\lib;D:\\lib'
    

(Note that Python requires that the backslash separators in a Windows path name be escaped within strings.)

When the linker is executed, SCons will create appropriate flags so that the linker will look for libraries in the same directories as SCons. So on a POSIX or Linux system, a build of the above example would look like:

% scons -Q
cc -o prog.o -c prog.c
cc -o prog prog.o -L/usr/lib -L/usr/local/lib -lm

On a Windows system, a build of the above example would look like:

C:\>scons -Q
cl /Foprog.obj /c prog.c /nologo
link /nologo /OUT:prog.exe /LIBPATH:\usr\lib /LIBPATH:\usr\local\lib m.lib prog.obj
embedManifestExeCheck(target, source, env)

Note again that SCons has taken care of the system-specific details of creating the right command-line options.

All builder methods return a list of Node objects that identify the target file or files that will be built. These returned Nodes can be passed as arguments to other builder methods.

For example, suppose that we want to build the two object files that make up a program with different options. This would mean calling the Object builder once for each object file, specifying the desired options:

Object('hello.c', CCFLAGS='-DHELLO')
Object('goodbye.c', CCFLAGS='-DGOODBYE')
    

One way to combine these object files into the resulting program would be to call the Program builder with the names of the object files listed as sources:

Object('hello.c', CCFLAGS='-DHELLO')
Object('goodbye.c', CCFLAGS='-DGOODBYE')
Program(['hello.o', 'goodbye.o'])
    

The problem with specifying the names as strings is that our SConstruct file is no longer portable across operating systems. It won't, for example, work on Windows because the object files there would be named hello.obj and goodbye.obj, not hello.o and goodbye.o.

A better solution is to assign the lists of targets returned by the calls to the Object builder to variables, which we can then concatenate in our call to the Program builder:

hello_list = Object('hello.c', CCFLAGS='-DHELLO')
goodbye_list = Object('goodbye.c', CCFLAGS='-DGOODBYE')
Program(hello_list + goodbye_list)
      

This makes our SConstruct file portable again, the build output on Linux looking like:

% scons -Q
cc -o goodbye.o -c -DGOODBYE goodbye.c
cc -o hello.o -c -DHELLO hello.c
cc -o hello hello.o goodbye.o

And on Windows:

C:\>scons -Q
cl /Fogoodbye.obj /c goodbye.c -DGOODBYE
cl /Fohello.obj /c hello.c -DHELLO
link /nologo /OUT:hello.exe hello.obj goodbye.obj
embedManifestExeCheck(target, source, env)

We'll see examples of using the list of nodes returned by builder methods throughout the rest of this guide.

It's worth mentioning here that SCons maintains a clear distinction between Nodes that represent files and Nodes that represent directories. SCons supports File and Dir functions that, respectively, return a file or directory Node:

hello_c = File('hello.c')
Program(hello_c)

classes = Dir('classes')
Java(classes, 'src')
      

Normally, you don't need to call File or Dir directly, because calling a builder method automatically treats strings as the names of files or directories, and translates them into the Node objects for you. The File and Dir functions can come in handy in situations where you need to explicitly instruct SCons about the type of Node being passed to a builder or other function, or unambiguously refer to a specific file in a directory tree.

There are also times when you may need to refer to an entry in a file system without knowing in advance whether it's a file or a directory. For those situations, SCons also supports an Entry function, which returns a Node that can represent either a file or a directory.

xyzzy = Entry('xyzzy')
    

The returned xyzzy Node will be turned into a file or directory Node the first time it is used by a builder method or other function that requires one vs. the other.

One of the most common things you can do with a Node is use it to print the file name that the node represents. Keep in mind, though, that because the object returned by a builder call is a list of Nodes, you must use Python subscripts to fetch individual Nodes from the list. For example, the following SConstruct file:

object_list = Object('hello.c')
program_list = Program(object_list)
print("The object file is: %s"%object_list[0])
print("The program file is: %s"%program_list[0])
      

Would print the following file names on a POSIX system:

% scons -Q
The object file is: hello.o
The program file is: hello
cc -o hello.o -c hello.c
cc -o hello hello.o

And the following file names on a Windows system:

C:\>scons -Q
The object file is: hello.obj
The program file is: hello.exe
cl /Fohello.obj /c hello.c /nologo
link /nologo /OUT:hello.exe hello.obj
embedManifestExeCheck(target, source, env)

Note that in the above example, the object_list[0] extracts an actual Node object from the list, and the Python print statement converts the object to a string for printing.

Printing a Node's name as described in the previous section works because the string representation of a Node object is the name of the file. If you want to do something other than print the name of the file, you can fetch it by using the builtin Python str function. For example, if you want to use the Python os.path.exists to figure out whether a file exists while the SConstruct file is being read and executed, you can fetch the string as follows:

import os.path
program_list = Program('hello.c')
program_name = str(program_list[0])
if not os.path.exists(program_name):
    print("%s does not exist!"%program_name)
      

Which executes as follows on a POSIX system:

% scons -Q
hello does not exist!
cc -o hello.o -c hello.c
cc -o hello hello.o

env.GetBuildPath(file_or_list) returns the path of a Node or a string representing a path. It can also take a list of Nodes and/or strings, and returns the list of paths. If passed a single Node, the result is the same as calling str(node) (see above). The string(s) can have embedded construction variables, which are expanded as usual, using the calling environment's set of variables. The paths can be files or directories, and do not have to exist.

env=Environment(VAR="value")
n=File("foo.c")
print(env.GetBuildPath([n, "sub/dir/$VAR"]))
      

Would print the following file names:

% scons -Q
['foo.c', 'sub/dir/value']
scons: `.' is up to date.

There is also a function version of GetBuildPath which can be called without an Environment; that uses the default SCons Environment to do substitution on any string arguments.

Another aspect of avoiding unnecessary rebuilds is the fundamental build tool behavior of rebuilding things when an input file changes, so that the built software is up to date. By default, SCons keeps track of this through an MD5 signature, or checksum, of the contents of each file, although you can easily configure SCons to use the modification times (or time stamps) instead. You can even specify your own Python function for deciding if an input file has changed.

% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o
% touch hello.c
% scons -Q hello
scons: `hello' is up to date.

% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o
%     [CHANGE THE CONTENTS OF hello.c]
% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o

Program('hello.c')
Decider('MD5')
      

% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o
%   [CHANGE A COMMENT IN hello.c]
% scons -Q hello
cc -o hello.o -c hello.c
scons: `hello' is up to date.

Object('hello.c')
Decider('timestamp-newer')
        

% scons -Q hello.o
cc -o hello.o -c hello.c
% touch hello.c
% scons -Q hello.o
cc -o hello.o -c hello.c

Object('hello.c')
Decider('make')
      

Object('hello.c')
Decider('timestamp-match')
        

% scons -Q hello.o
cc -o hello.o -c hello.c
% touch -t 198901010000 hello.c
% scons -Q hello.o
cc -o hello.o -c hello.c

Program('hello.c')
Decider('MD5-timestamp')
        

% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o
% touch hello.c
% scons -Q hello
scons: `hello' is up to date.
% edit hello.c
    [CHANGE THE CONTENTS OF hello.c]
% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o
      

Program('hello.c')
def decide_if_changed(dependency, target, prev_ni):
    if dependency.get_timestamp() != prev_ni.timestamp:
        dep = str(dependency)
        tgt = str(target)
        if specific_part_of_file_has_changed(dep, tgt):
            return True
    return False
Decider(decide_if_changed)
        

env = Environment()

def config_file_decider(dependency, target, prev_ni):
    import os.path

    # We always have to init the .csig value...
    dep_csig = dependency.get_csig()
    # .csig may not exist, because no target was built yet...
    if 'csig' not in dir(prev_ni):
        return True
    # Target file may not exist yet
    if not os.path.exists(str(target.abspath)):
        return True
    if dep_csig != prev_ni.csig:
        # Some change on source file => update installed one
        return True
    return False

def update_file():
    f = open("test.txt","a")
    f.write("some line\n")
    f.close()

update_file()

# Activate our own decider function
env.Decider(config_file_decider)

env.Install("install","test.txt")
      

env1 = Environment(CPPPATH = ['.'])
env2 = env1.Clone()
env2.Decider('timestamp-match')
env1.Program('prog-MD5', 'program1.c')
env2.Program('prog-timestamp', 'program2.c')
        

% scons -Q
cc -o program1.o -c -I. program1.c
cc -o prog-MD5 program1.o
cc -o program2.o -c -I. program2.c
cc -o prog-timestamp program2.o
% touch inc.h
% scons -Q
cc -o program2.o -c -I. program2.c
cc -o prog-timestamp program2.o

SCons still supports two functions that used to be the primary methods for configuring the decision about whether or not an input file has changed. These functions have been officially deprecated as SCons version 2.0, and their use is discouraged, mainly because they rely on a somewhat confusing distinction between how source files and target files are handled. These functions are documented here mainly in case you encounter them in older SConscript files.

Program('hello.c')
SourceSignatures('MD5')
      

Program('hello.c')
SourceSignatures('timestamp')
      

Program('hello.c')
TargetSignatures('MD5')
      

Program('hello.c')
TargetSignatures('timestamp')
      

Program('hello.c')
TargetSignatures('source')
SourceSignatures('timestamp')
      

Now suppose that our "Hello, World!" program actually has an #include line to include the hello.h file in the compilation:

#include <hello.h>
int
main()
{
    printf("Hello, %s!\n", string);
}
      

And, for completeness, the hello.h file looks like this:

#define string    "world"
      

In this case, we want SCons to recognize that, if the contents of the hello.h file change, the hello program must be recompiled. To do this, we need to modify the SConstruct file like so:

Program('hello.c', CPPPATH = '.')
      

The $CPPPATH value tells SCons to look in the current directory ('.') for any files included by C source files (.c or .h files). With this assignment in the SConstruct file:

% scons -Q hello
cc -o hello.o -c -I. hello.c
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.
%     [CHANGE THE CONTENTS OF hello.h]
% scons -Q hello
cc -o hello.o -c -I. hello.c
cc -o hello hello.o

First, notice that SCons added the -I. argument from the $CPPPATH variable so that the compilation would find the hello.h file in the local directory.

Second, realize that SCons knows that the hello program must be rebuilt because it scans the contents of the hello.c file for the #include lines that indicate another file is being included in the compilation. SCons records these as implicit dependencies of the target file, Consequently, when the hello.h file changes, SCons realizes that the hello.c file includes it, and rebuilds the resulting hello program that depends on both the hello.c and hello.h files.

Like the $LIBPATH variable, the $CPPPATH variable may be a list of directories, or a string separated by the system-specific path separation character (':' on POSIX/Linux, ';' on Windows). Either way, SCons creates the right command-line options so that the following example:

Program('hello.c', CPPPATH = ['include', '/home/project/inc'])
      

Will look like this on POSIX or Linux:

% scons -Q hello
cc -o hello.o -c -Iinclude -I/home/project/inc hello.c
cc -o hello hello.o

And like this on Windows:

C:\>scons -Q hello.exe
cl /Fohello.obj /c hello.c /nologo /Iinclude /I\home\project\inc
link /nologo /OUT:hello.exe hello.obj
embedManifestExeCheck(target, source, env)

Scanning each file for #include lines does take some extra processing time. When you're doing a full build of a large system, the scanning time is usually a very small percentage of the overall time spent on the build. You're most likely to notice the scanning time, however, when you rebuild all or part of a large system: SCons will likely take some extra time to "think about" what must be built before it issues the first build command (or decides that everything is up to date and nothing must be rebuilt).

In practice, having SCons scan files saves time relative to the amount of potential time lost to tracking down subtle problems introduced by incorrect dependencies. Nevertheless, the "waiting time" while SCons scans files can annoy individual developers waiting for their builds to finish. Consequently, SCons lets you cache the implicit dependencies that its scanners find, for use by later builds. You can do this by specifying the --implicit-cache option on the command line:

% scons -Q --implicit-cache hello
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.

If you don't want to specify --implicit-cache on the command line each time, you can make it the default behavior for your build by setting the implicit_cache option in an SConscript file:

SetOption('implicit_cache', 1)
    

SCons does not cache implicit dependencies like this by default because the --implicit-cache causes SCons to simply use the implicit dependencies stored during the last run, without any checking for whether or not those dependencies are still correct. Specifically, this means --implicit-cache instructs SCons to not rebuild "correctly" in the following cases:

% scons -Q --implicit-deps-changed hello
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.

% scons -Q --implicit-deps-unchanged hello
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.

Sometimes a file depends on another file that is not detected by an SCons scanner. For this situation, SCons allows you to specific explicitly that one file depends on another file, and must be rebuilt whenever that file changes. This is specified using the Depends method:

hello = Program('hello.c')
Depends(hello, 'other_file')
    

% scons -Q hello
cc -c hello.c -o hello.o
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.
% edit other_file
    [CHANGE THE CONTENTS OF other_file]
% scons -Q hello
cc -c hello.c -o hello.o
cc -o hello hello.o
    

Note that the dependency (the second argument to Depends) may also be a list of Node objects (for example, as returned by a call to a Builder):

hello = Program('hello.c')
goodbye = Program('goodbye.c')
Depends(hello, goodbye)
    

in which case the dependency or dependencies will be built before the target(s):

% scons -Q hello
cc -c goodbye.c -o goodbye.o
cc -o goodbye goodbye.o
cc -c hello.c -o hello.o
cc -o hello hello.o
    

SCons has built-in scanners for a number of languages. Sometimes these scanners fail to extract certain implicit dependencies due to limitations of the scanner implementation.

The following example illustrates a case where the built-in C scanner is unable to extract the implicit dependency on a header file.

#define FOO_HEADER <foo.h>
#include FOO_HEADER

int main() {
    return FOO;
}
      

% scons -Q
cc -o hello.o -c -I. hello.c
cc -o hello hello.o
%    [CHANGE CONTENTS OF foo.h]
% scons -Q
scons: `.' is up to date.

Apparently, the scanner does not know about the header dependency. Being not a full-fledged C preprocessor, the scanner does not expand the macro.

In these cases, you may also use the compiler to extract the implicit dependencies. ParseDepends can parse the contents of the compiler output in the style of Make, and explicitly establish all of the listed dependencies.

The following example uses ParseDepends to process a compiler generated dependency file which is generated as a side effect during compilation of the object file:

obj = Object('hello.c', CCFLAGS='-MD -MF hello.d', CPPPATH='.')
SideEffect('hello.d', obj)
ParseDepends('hello.d')
Program('hello', obj)
      

% scons -Q
cc -o hello.o -c -MD -MF hello.d -I. hello.c
cc -o hello hello.o
%    [CHANGE CONTENTS OF foo.h]
% scons -Q
cc -o hello.o -c -MD -MF hello.d -I. hello.c

Parsing dependencies from a compiler-generated .d file has a chicken-and-egg problem, that causes unnecessary rebuilds:

% scons -Q
cc -o hello.o -c -MD -MF hello.d -I. hello.c
cc -o hello hello.o
% scons -Q --debug=explain
scons: rebuilding `hello.o' because `foo.h' is a new dependency
cc -o hello.o -c -MD -MF hello.d -I. hello.c
% scons -Q
scons: `.' is up to date.
    

In the first pass, the dependency file is generated while the object file is compiled. At that time, SCons does not know about the dependency on foo.h. In the second pass, the object file is regenerated because foo.h is detected as a new dependency.

ParseDepends immediately reads the specified file at invocation time and just returns if the file does not exist. A dependency file generated during the build process is not automatically parsed again. Hence, the compiler-extracted dependencies are not stored in the signature database during the same build pass. This limitation of ParseDepends leads to unnecessary recompilations. Therefore, ParseDepends should only be used if scanners are not available for the employed language or not powerful enough for the specific task.

Sometimes it makes sense to not rebuild a program, even if a dependency file changes. In this case, you would tell SCons specifically to ignore a dependency as follows:

hello_obj=Object('hello.c')
hello = Program(hello_obj)
Ignore(hello_obj, 'hello.h')
      

% scons -Q hello
cc -c -o hello.o hello.c
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.
% edit hello.h
  [CHANGE THE CONTENTS OF hello.h]
% scons -Q hello
scons: `hello' is up to date.
    

Now, the above example is a little contrived, because it's hard to imagine a real-world situation where you wouldn't want to rebuild hello if the hello.h file changed. A more realistic example might be if the hello program is being built in a directory that is shared between multiple systems that have different copies of the stdio.h include file. In that case, SCons would notice the differences between the different systems' copies of stdio.h and would rebuild hello each time you change systems. You could avoid these rebuilds as follows:

hello = Program('hello.c', CPPPATH=['/usr/include'])
Ignore(hello, '/usr/include/stdio.h')
    

Ignore can also be used to prevent a generated file from being built by default. This is due to the fact that directories depend on their contents. So to ignore a generated file from the default build, you specify that the directory should ignore the generated file. Note that the file will still be built if the user specifically requests the target on scons command line, or if the file is a dependency of another file which is requested and/or is built by default.

hello_obj=Object('hello.c')
hello = Program(hello_obj)
Ignore('.',[hello,hello_obj])
      

% scons -Q
scons: `.' is up to date.
% scons -Q hello
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q hello
scons: `hello' is up to date.

Occasionally, it may be useful to specify that a certain file or directory must, if necessary, be built or created before some other target is built, but that changes to that file or directory do not require that the target itself be rebuilt. Such a relationship is called an order-only dependency because it only affects the order in which things must be built--the dependency before the target--but it is not a strict dependency relationship because the target should not change in response to changes in the dependent file.

For example, suppose that you want to create a file every time you run a build that identifies the time the build was performed, the version number, etc., and which is included in every program that you build. The version file's contents will change every build. If you specify a normal dependency relationship, then every program that depends on that file would be rebuilt every time you ran SCons. For example, we could use some Python code in a SConstruct file to create a new version.c file with a string containing the current date every time we run SCons, and then link a program with the resulting object file by listing version.c in the sources:

import time

version_c_text = """
char *date = "%s";
""" % time.ctime(time.time())
open('version.c', 'w').write(version_c_text)

hello = Program(['hello.c', 'version.c'])
      

If we list version.c as an actual source file, though, then the version.o file will get rebuilt every time we run SCons (because the SConstruct file itself changes the contents of version.c) and the hello executable will get re-linked every time (because the version.o file changes):

% scons -Q hello
cc -o hello.o -c hello.c
cc -o version.o -c version.c
cc -o hello hello.o version.o
% sleep 1
% scons -Q hello
cc -o version.o -c version.c
cc -o hello hello.o version.o
% sleep 1
% scons -Q hello
cc -o version.o -c version.c
cc -o hello hello.o version.o

(Note that for the above example to work, we sleep for one second in between each run, so that the SConstruct file will create a version.c file with a time string that's one second later than the previous run.)

One solution is to use the Requires function to specify that the version.o must be rebuilt before it is used by the link step, but that changes to version.o should not actually cause the hello executable to be re-linked:

import time

version_c_text = """
char *date = "%s";
""" % time.ctime(time.time())
open('version.c', 'w').write(version_c_text)

version_obj = Object('version.c')

hello = Program('hello.c',
                LINKFLAGS = str(version_obj[0]))

Requires(hello, version_obj)
      

Notice that because we can no longer list version.c as one of the sources for the hello program, we have to find some other way to get it into the link command line. For this example, we're cheating a bit and stuffing the object file name (extracted from version_obj list returned by the Object call) into the $LINKFLAGS variable, because $LINKFLAGS is already included in the $LINKCOM command line.

With these changes, we get the desired behavior of only re-linking the hello executable when the hello.c has changed, even though the version.o is rebuilt (because the SConstruct file still changes the version.c contents directly each run):

% scons -Q hello
cc -o version.o -c version.c
cc -o hello.o -c hello.c
cc -o hello version.o hello.o
% sleep 1
% scons -Q hello
cc -o version.o -c version.c
scons: `hello' is up to date.
% sleep 1
%     [CHANGE THE CONTENTS OF hello.c]
% scons -Q hello
cc -o version.o -c version.c
cc -o hello.o -c hello.c
cc -o hello version.o hello.o
% sleep 1
% scons -Q hello
cc -o version.o -c version.c
scons: `hello' is up to date.

How SCons handles dependencies can also be affected by the AlwaysBuild method. When a file is passed to the AlwaysBuild method, like so:

hello = Program('hello.c')
AlwaysBuild(hello)
      

Then the specified target file (hello in our example) will always be considered out-of-date and rebuilt whenever that target file is evaluated while walking the dependency graph:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q
cc -o hello hello.o

The AlwaysBuild function has a somewhat misleading name, because it does not actually mean the target file will be rebuilt every single time SCons is invoked. Instead, it means that the target will, in fact, be rebuilt whenever the target file is encountered while evaluating the targets specified on the command line (and their dependencies). So specifying some other target on the command line, a target that does not itself depend on the AlwaysBuild target, will still be rebuilt only if it's out-of-date with respect to its dependencies:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q hello.o
scons: `hello.o' is up to date.

The external environment variable settings that the user has in force when executing SCons are available through the normal Python os.environ dictionary. This means that you must add an import os statement to any SConscript file in which you want to use values from the user's external environment.

import os
     

More usefully, you can use the os.environ dictionary in your SConscript files to initialize construction environments with values from the user's external environment. See the next section, Section 7.2, “Construction Environments”, for information on how to do this.

It is rare that all of the software in a large, complicated system needs to be built the same way. For example, different source files may need different options enabled on the command line, or different executable programs need to be linked with different libraries. SCons accommodates these different build requirements by allowing you to create and configure multiple construction environments that control how the software is built. A construction environment is an object that has a number of associated construction variables, each with a name and a value. (A construction environment also has an attached set of Builder methods, about which we'll learn more later.)

env = Environment()
       

 env = Environment(CC = 'gcc',
                   CCFLAGS = '-O2')

 env.Program('foo.c')
         

% scons -Q
gcc -o foo.o -c -O2 foo.c
gcc -o foo foo.o

env = Environment()
print("CC is: %s"%env['CC'])
        

% scons -Q
CC is: cc
scons: `.' is up to date.

env = Environment(FOO = 'foo', BAR = 'bar')
dict = env.Dictionary()
for key in ['OBJSUFFIX', 'LIBSUFFIX', 'PROGSUFFIX']:
    print("key = %s, value = %s" % (key, dict[key]))
         

% scons -Q
key = OBJSUFFIX, value = .o
key = LIBSUFFIX, value = .a
key = PROGSUFFIX, value = 
scons: `.' is up to date.

C:\>scons -Q
key = OBJSUFFIX, value = .obj
key = LIBSUFFIX, value = .lib
key = PROGSUFFIX, value = .exe
scons: `.' is up to date.

env = Environment()
for item in sorted(env.Dictionary().items()):
    print("construction variable = '%s', value = '%s'" % item)
      

env = Environment()
print("CC is: %s"%env.subst('$CC'))
      

env = Environment(CCFLAGS = '-DFOO')
print("CCCOM is: %s"%env['CCCOM'])
      

% scons -Q
CCCOM is: $CC $CCFLAGS $CPPFLAGS $_CPPDEFFLAGS $_CPPINCFLAGS -c -o $TARGET $SOURCES
scons: `.' is up to date.
      

env = Environment(CCFLAGS = '-DFOO')
print("CCCOM is: %s"%env.subst('$CCCOM'))
      

% scons -Q
CCCOM is: gcc -DFOO -c -o
scons: `.' is up to date.
      

env = Environment()
print("value is: %s"%env.subst( '->$MISSING<-' ))
        

% scons -Q
value is: -><-
scons: `.' is up to date.

AllowSubstExceptions()
env = Environment()
print("value is: %s"%env.subst( '->$MISSING<-' ))
        

% scons -Q

scons: *** NameError `MISSING' trying to evaluate `$MISSING'
File "/home/my/project/SConstruct", line 3, in <module>

AllowSubstExceptions(IndexError, NameError, ZeroDivisionError)
env = Environment()
print("value is: %s"%env.subst( '->${1 / 0}<-' ))
        

% scons -Q
value is: -><-
scons: `.' is up to date.

DefaultEnvironment(CC = '/usr/local/bin/gcc')
      

env = DefaultEnvironment()
env['CC'] = '/usr/local/bin/gcc'
      

env = DefaultEnvironment(tools = ['gcc', 'gnulink'],
                         CC = '/usr/local/bin/gcc')
      

opt = Environment(CCFLAGS = '-O2')
dbg = Environment(CCFLAGS = '-g')

opt.Program('foo', 'foo.c')

dbg.Program('bar', 'bar.c')
        

% scons -Q
cc -o bar.o -c -g bar.c
cc -o bar bar.o
cc -o foo.o -c -O2 foo.c
cc -o foo foo.o

opt = Environment(CCFLAGS = '-O2')
dbg = Environment(CCFLAGS = '-g')

opt.Program('foo', 'foo.c')

dbg.Program('foo', 'foo.c')
        

% scons -Q

scons: *** Two environments with different actions were specified for the same target: foo.o
File "/home/my/project/SConstruct", line 6, in <module>

opt = Environment(CCFLAGS = '-O2')
dbg = Environment(CCFLAGS = '-g')

o = opt.Object('foo-opt', 'foo.c')
opt.Program(o)

d = dbg.Object('foo-dbg', 'foo.c')
dbg.Program(d)
        

% scons -Q
cc -o foo-dbg.o -c -g foo.c
cc -o foo-dbg foo-dbg.o
cc -o foo-opt.o -c -O2 foo.c
cc -o foo-opt foo-opt.o

env = Environment(CC = 'gcc')
opt = env.Clone(CCFLAGS = '-O2')
dbg = env.Clone(CCFLAGS = '-g')

env.Program('foo', 'foo.c')

o = opt.Object('foo-opt', 'foo.c')
opt.Program(o)

d = dbg.Object('foo-dbg', 'foo.c')
dbg.Program(d)
        

% scons -Q
gcc -o foo.o -c foo.c
gcc -o foo foo.o
gcc -o foo-dbg.o -c -g foo.c
gcc -o foo-dbg foo-dbg.o
gcc -o foo-opt.o -c -O2 foo.c
gcc -o foo-opt foo-opt.o

env = Environment(CCFLAGS = '-DDEFINE1')
env.Replace(CCFLAGS = '-DDEFINE2')
env.Program('foo.c')
        

% scons -Q
cc -o foo.o -c -DDEFINE2 foo.c
cc -o foo foo.o

env = Environment()
env.Replace(NEW_VARIABLE = 'xyzzy')
print("NEW_VARIABLE = %s"%env['NEW_VARIABLE'])
        

% scons -Q
NEW_VARIABLE = xyzzy
scons: `.' is up to date.

env = Environment(CCFLAGS = '-DDEFINE1')
print("CCFLAGS = %s"%env['CCFLAGS'])
env.Program('foo.c')

env.Replace(CCFLAGS = '-DDEFINE2')
print("CCFLAGS = %s"%env['CCFLAGS'])
env.Program('bar.c')
        

% scons
scons: Reading SConscript files ...
CCFLAGS = -DDEFINE1
CCFLAGS = -DDEFINE2
scons: done reading SConscript files.
scons: Building targets ...
cc -o bar.o -c -DDEFINE2 bar.c
cc -o bar bar.o
cc -o foo.o -c -DDEFINE2 foo.c
cc -o foo foo.o
scons: done building targets.

env.SetDefault(SPECIAL_FLAG = '-extra-option')
      

env = Environment(CCFLAGS = ['-DMY_VALUE'])
env.Append(CCFLAGS = ['-DLAST'])
env.Program('foo.c')
        

% scons -Q
cc -o foo.o -c -DMY_VALUE -DLAST foo.c
cc -o foo foo.o

env = Environment()
env.Append(NEW_VARIABLE = 'added')
print("NEW_VARIABLE = %s"%env['NEW_VARIABLE'])
        

% scons -Q
NEW_VARIABLE = added
scons: `.' is up to date.

env.AppendUnique(CCFLAGS=['-g'])
      

env = Environment(CCFLAGS = ['-DMY_VALUE'])
env.Prepend(CCFLAGS = ['-DFIRST'])
env.Program('foo.c')
        

% scons -Q
cc -o foo.o -c -DFIRST -DMY_VALUE foo.c
cc -o foo foo.o

env = Environment()
env.Prepend(NEW_VARIABLE = 'added')
print("NEW_VARIABLE = %s"%env['NEW_VARIABLE'])
        

% scons -Q
NEW_VARIABLE = added
scons: `.' is up to date.

env.PrependUnique(CCFLAGS=['-g'])
      

When SCons builds a target file, it does not execute the commands with the same external environment that you used to execute SCons. Instead, it uses the dictionary stored in the $ENV construction variable as the external environment for executing commands.

The most important ramification of this behavior is that the PATH environment variable, which controls where the operating system will look for commands and utilities, is not the same as in the external environment from which you called SCons. This means that SCons will not, by default, necessarily find all of the tools that you can execute from the command line.

The default value of the PATH environment variable on a POSIX system is /usr/local/bin:/bin:/usr/bin. The default value of the PATH environment variable on a Windows system comes from the Windows registry value for the command interpreter. If you want to execute any commands--compilers, linkers, etc.--that are not in these default locations, you need to set the PATH value in the $ENV dictionary in your construction environment.

The simplest way to do this is to initialize explicitly the value when you create the construction environment; this is one way to do that:

path = ['/usr/local/bin', '/bin', '/usr/bin']
env = Environment(ENV = {'PATH' : path})
    

Assign a dictionary to the $ENV construction variable in this way completely resets the external environment so that the only variable that will be set when external commands are executed will be the PATH value. If you want to use the rest of the values in $ENV and only set the value of PATH, the most straightforward way is probably:

env['ENV']['PATH'] = ['/usr/local/bin', '/bin', '/usr/bin']
    

Note that SCons does allow you to define the directories in the PATH in a string, separated by the pathname-separator character for your system (':' on POSIX systems, ';' on Windows):

env['ENV']['PATH'] = '/usr/local/bin:/bin:/usr/bin'
    

But doing so makes your SConscript file less portable, (although in this case that may not be a huge concern since the directories you list are likely system-specific, anyway).

import os
env = Environment(ENV = {'PATH' : os.environ['PATH']})
      

import os
env = Environment(ENV = os.environ)
      

env = Environment(ENV = os.environ)
env.PrependENVPath('PATH', '/usr/local/bin')
env.AppendENVPath('LIB', '/usr/local/lib')
      

SCons construction environments have a MergeFlags method that merges a dictionary of values into the construction environment. MergeFlags treats each value in the dictionary as a list of options such as one might pass to a command (such as a compiler or linker). MergeFlags will not duplicate an option if it already exists in the construction environment variable.

MergeFlags tries to be intelligent about merging options. When merging options to any variable whose name ends in PATH, MergeFlags keeps the leftmost occurrence of the option, because in typical lists of directory paths, the first occurrence "wins." When merging options to any other variable name, MergeFlags keeps the rightmost occurrence of the option, because in a list of typical command-line options, the last occurrence "wins."

env = Environment()
env.Append(CCFLAGS = '-option -O3 -O1')
flags = { 'CCFLAGS' : '-whatever -O3' }
env.MergeFlags(flags)
print env['CCFLAGS']
   

% scons -Q
['-option', '-O1', '-whatever', '-O3']
scons: `.' is up to date.

Note that the default value for $CCFLAGS is an internal SCons object which automatically converts the options we specified as a string into a list.

env = Environment()
env.Append(CPPPATH = ['/include', '/usr/local/include', '/usr/include'])
flags = { 'CPPPATH' : ['/usr/opt/include', '/usr/local/include'] }
env.MergeFlags(flags)
print env['CPPPATH']
   

% scons -Q
['/include', '/usr/local/include', '/usr/include', '/usr/opt/include']
scons: `.' is up to date.

Note that the default value for $CPPPATH is a normal Python list, so we must specify its values as a list in the dictionary we pass to the MergeFlags function.

If MergeFlags is passed anything other than a dictionary, it calls the ParseFlags method to convert it into a dictionary.

env = Environment()
env.Append(CCFLAGS = '-option -O3 -O1')
env.Append(CPPPATH = ['/include', '/usr/local/include', '/usr/include'])
env.MergeFlags('-whatever -I/usr/opt/include -O3 -I/usr/local/include')
print env['CCFLAGS']
print env['CPPPATH']
   

% scons -Q
['-option', '-O1', '-whatever', '-O3']
['/include', '/usr/local/include', '/usr/include', '/usr/opt/include']
scons: `.' is up to date.

In the combined example above, ParseFlags has sorted the options into their corresponding variables and returned a dictionary for MergeFlags to apply to the construction variables in the specified construction environment.

SCons has a bewildering array of construction variables for different types of options when building programs. Sometimes you may not know exactly which variable should be used for a particular option.

SCons construction environments have a ParseFlags method that takes a set of typical command-line options and distributes them into the appropriate construction variables. Historically, it was created to support the ParseConfig method, so it focuses on options used by the GNU Compiler Collection (GCC) for the C and C++ toolchains.

ParseFlags returns a dictionary containing the options distributed into their respective construction variables. Normally, this dictionary would be passed to MergeFlags to merge the options into a construction environment, but the dictionary can be edited if desired to provide additional functionality. (Note that if the flags are not going to be edited, calling MergeFlags with the options directly will avoid an additional step.)

env = Environment()
d = env.ParseFlags("-I/opt/include -L/opt/lib -lfoo")
for k,v in sorted(d.items()):
    if v:
        print k, v
env.MergeFlags(d)
env.Program('f1.c')
   

% scons -Q
CPPPATH ['/opt/include']
LIBPATH ['/opt/lib']
LIBS ['foo']
cc -o f1.o -c -I/opt/include f1.c
cc -o f1 f1.o -L/opt/lib -lfoo

Note that if the options are limited to generic types like those above, they will be correctly translated for other platform types:

C:\>scons -Q
CPPPATH ['/opt/include']
LIBPATH ['/opt/lib']
LIBS ['foo']
cl /Fof1.obj /c f1.c /nologo /I\opt\include
link /nologo /OUT:f1.exe /LIBPATH:\opt\lib foo.lib f1.obj
embedManifestExeCheck(target, source, env)

Since the assumption is that the flags are used for the GCC toolchain, unrecognized flags are placed in $CCFLAGS so they will be used for both C and C++ compiles:

env = Environment()
d = env.ParseFlags("-whatever")
for k,v in sorted(d.items()):
    if v:
        print k, v
env.MergeFlags(d)
env.Program('f1.c')
   

% scons -Q
CCFLAGS -whatever
cc -o f1.o -c -whatever f1.c
cc -o f1 f1.o

ParseFlags will also accept a (recursive) list of strings as input; the list is flattened before the strings are processed:

env = Environment()
d = env.ParseFlags(["-I/opt/include", ["-L/opt/lib", "-lfoo"]])
for k,v in sorted(d.items()):
    if v:
        print k, v
env.MergeFlags(d)
env.Program('f1.c')
   

% scons -Q
CPPPATH ['/opt/include']
LIBPATH ['/opt/lib']
LIBS ['foo']
cc -o f1.o -c -I/opt/include f1.c
cc -o f1 f1.o -L/opt/lib -lfoo

If a string begins with a "!" (an exclamation mark, often called a bang), the string is passed to the shell for execution. The output of the command is then parsed:

env = Environment()
d = env.ParseFlags(["!echo -I/opt/include", "!echo -L/opt/lib", "-lfoo"])
for k,v in sorted(d.items()):
    if v:
        print k, v
env.MergeFlags(d)
env.Program('f1.c')
   

% scons -Q
CPPPATH ['/opt/include']
LIBPATH ['/opt/lib']
LIBS ['foo']
cc -o f1.o -c -I/opt/include f1.c
cc -o f1 f1.o -L/opt/lib -lfoo

ParseFlags is regularly updated for new options; consult the man page for details about those currently recognized.

Configuring the right options to build programs to work with libraries--especially shared libraries--that are available on POSIX systems can be very complicated. To help this situation, various utilies with names that end in config return the command-line options for the GNU Compiler Collection (GCC) that are needed to use these libraries; for example, the command-line options to use a library named lib would be found by calling a utility named lib-config.

A more recent convention is that these options are available from the generic pkg-config program, which has common framework, error handling, and the like, so that all the package creator has to do is provide the set of strings for his particular package.

SCons construction environments have a ParseConfig method that executes a *config utility (either pkg-config or a more specific utility) and configures the appropriate construction variables in the environment based on the command-line options returned by the specified command.

env = Environment()
env['CPPPATH'] = ['/lib/compat']
env.ParseConfig("pkg-config x11 --cflags --libs")
print env['CPPPATH']
   

SCons will execute the specified command string, parse the resultant flags, and add the flags to the appropriate environment variables.

% scons -Q
['/lib/compat', '/usr/X11/include']
scons: `.' is up to date.
 

In the example above, SCons has added the include directory to CPPPATH. (Depending upon what other flags are emitted by the pkg-config command, other variables may have been extended as well.)

Note that the options are merged with existing options using the MergeFlags method, so that each option only occurs once in the construction variable:

env = Environment()
env.ParseConfig("pkg-config x11 --cflags --libs")
env.ParseConfig("pkg-config x11 --cflags --libs")
print env['CPPPATH']
   

% scons -Q
['/usr/X11/include']
scons: `.' is up to date.
 

It's often very useful to be able to give users some help that describes the specific targets, build options, etc., that can be used for your build. SCons provides the Help function to allow you to specify this help text:

Help("""
Type: 'scons program' to build the production program,
      'scons debug' to build the debug version.
""")
       

Optionally, one can specify the append flag:

Help("""
Type: 'scons program' to build the production program,
      'scons debug' to build the debug version.
""", append=True)
       

(Note the above use of the Python triple-quote syntax, which comes in very handy for specifying multi-line strings like help text.)

When the SConstruct or SConscript files contain such a call to the Help function, the specified help text will be displayed in response to the SCons -h option:

% scons -h
scons: Reading SConscript files ...
scons: done reading SConscript files.

Type: 'scons program' to build the production program,
      'scons debug' to build the debug version.

Use scons -H for help about command-line options.

The SConscript files may contain multiple calls to the Help function, in which case the specified text(s) will be concatenated when displayed. This allows you to split up the help text across multiple SConscript files. In this situation, the order in which the SConscript files are called will determine the order in which the Help functions are called, which will determine the order in which the various bits of text will get concatenated.

When used with AddOption Help("text", append=False) will clobber any help output associated with AddOption(). To preserve the help output from AddOption(), set append=True.

Another use would be to make the help text conditional on some variable. For example, suppose you only want to display a line about building a Windows-only version of a program when actually run on Windows. The following SConstruct file:

env = Environment()

Help("\nType: 'scons program' to build the production program.\n")

if env['PLATFORM'] == 'win32':
    Help("\nType: 'scons windebug' to build the Windows debug version.\n")
       

Will display the complete help text on Windows:

C:\>scons -h
scons: Reading SConscript files ...
scons: done reading SConscript files.

Type: 'scons program' to build the production program.

Type: 'scons windebug' to build the Windows debug version.

Use scons -H for help about command-line options.

But only show the relevant option on a Linux or UNIX system:

% scons -h
scons: Reading SConscript files ...
scons: done reading SConscript files.

Type: 'scons program' to build the production program.

Use scons -H for help about command-line options.

If there is no Help text in the SConstruct or SConscript files, SCons will revert to displaying its standard list that describes the SCons command-line options. This list is also always displayed whenever the -H option is used.

Sometimes the commands executed to compile object files or link programs (or build other targets) can get very long, long enough to make it difficult for users to distinguish error messages or other important build output from the commands themselves. All of the default $*COM variables that specify the command lines used to build various types of target files have a corresponding $*COMSTR variable that can be set to an alternative string that will be displayed when the target is built.

For example, suppose you want to have SCons display a "Compiling" message whenever it's compiling an object file, and a "Linking" when it's linking an executable. You could write a SConstruct file that looks like:

env = Environment(CCCOMSTR = "Compiling $TARGET",
                  LINKCOMSTR = "Linking $TARGET")
env.Program('foo.c')
       

Which would then yield the output:

% scons -Q
Compiling foo.o
Linking foo
    

SCons performs complete variable substitution on $*COMSTR variables, so they have access to all of the standard variables like $TARGET $SOURCES, etc., as well as any construction variables that happen to be configured in the construction environment used to build a specific target.

Of course, sometimes it's still important to be able to see the exact command that SCons will execute to build a target. For example, you may simply need to verify that SCons is configured to supply the right options to the compiler, or a developer may want to cut-and-paste a compile command to add a few options for a custom test.

One common way to give users control over whether or not SCons should print the actual command line or a short, configured summary is to add support for a VERBOSE command-line variable to your SConstruct file. A simple configuration for this might look like:

env = Environment()
if ARGUMENTS.get('VERBOSE') != "1':
    env['CCCOMSTR'] = "Compiling $TARGET"
    env['LINKCOMSTR'] = "Linking $TARGET"
env.Program('foo.c')
       

By only setting the appropriate $*COMSTR variables if the user specifies VERBOSE=1 on the command line, the user has control over how SCons displays these particular command lines:

% scons -Q
Compiling foo.o
Linking foo
% scons -Q -c
Removed foo.o
Removed foo
% scons -Q VERBOSE=1
cc -o foo.o -c foo.c
cc -o foo foo.o
    

Another aspect of providing good build output is to give the user feedback about what SCons is doing even when nothing is being built at the moment. This can be especially true for large builds when most of the targets are already up-to-date. Because SCons can take a long time making absolutely sure that every target is, in fact, up-to-date with respect to a lot of dependency files, it can be easy for users to mistakenly conclude that SCons is hung or that there is some other problem with the build.

One way to deal with this perception is to configure SCons to print something to let the user know what it's "thinking about." The Progress function allows you to specify a string that will be printed for every file that SCons is "considering" while it is traversing the dependency graph to decide what targets are or are not up-to-date.

Progress('Evaluating $TARGET\n')
Program('f1.c')
Program('f2.c')
      

Note that the Progress function does not arrange for a newline to be printed automatically at the end of the string (as does the Python print statement), and we must specify the \n that we want printed at the end of the configured string. This configuration, then, will have SCons print that it is Evaluating each file that it encounters in turn as it traverses the dependency graph:

% scons -Q
Evaluating SConstruct
Evaluating f1.c
Evaluating f1.o
cc -o f1.o -c f1.c
Evaluating f1
cc -o f1 f1.o
Evaluating f2.c
Evaluating f2.o
cc -o f2.o -c f2.c
Evaluating f2
cc -o f2 f2.o
Evaluating .

Of course, normally you don't want to add all of these additional lines to your build output, as that can make it difficult for the user to find errors or other important messages. A more useful way to display this progress might be to have the file names printed directly to the user's screen, not to the same standard output stream where build output is printed, and to use a carriage return character (\r) so that each file name gets re-printed on the same line. Such a configuration would look like:

Progress('$TARGET\r',
         file=open('/dev/tty', 'w'),
         overwrite=True)
Program('f1.c')
Program('f2.c')
    

Note that we also specified the overwrite=True argument to the Progress function, which causes SCons to "wipe out" the previous string with space characters before printing the next Progress string. Without the overwrite=True argument, a shorter file name would not overwrite all of the charactes in a longer file name that precedes it, making it difficult to tell what the actual file name is on the output. Also note that we opened up the /dev/tty file for direct access (on POSIX) to the user's screen. On Windows, the equivalent would be to open the con: file name.

Also, it's important to know that although you can use $TARGET to substitute the name of the node in the string, the Progress function does not perform general variable substitution (because there's not necessarily a construction environment involved in evaluating a node like a source file, for example).

You can also specify a list of strings to the Progress function, in which case SCons will display each string in turn. This can be used to implement a "spinner" by having SCons cycle through a sequence of strings:

Progress(['-\r', '\\\r', '|\r', '/\r'], interval=5)
Program('f1.c')
Program('f2.c')
    

Note that here we have also used the interval= keyword argument to have SCons only print a new "spinner" string once every five evaluated nodes. Using an interval= count, even with strings that use $TARGET like our examples above, can be a good way to lessen the work that SCons expends printing Progress strings, while still giving the user feedback that indicates SCons is still working on evaluating the build.

Lastly, you can have direct control over how to print each evaluated node by passing a Python function (or other Python callable) to the Progress function. Your function will be called for each evaluated node, allowing you to implement more sophisticated logic like adding a counter:

screen = open('/dev/tty', 'w')
count = 0
def progress_function(node)
    count += 1
    screen.write('Node %4d: %s\r' % (count, node))

Progress(progress_function)
      

Of course, if you choose, you could completely ignore the node argument to the function, and just print a count, or anything else you wish.

(Note that there's an obvious follow-on question here: how would you find the total number of nodes that will be evaluated so you can tell the user how close the build is to finishing? Unfortunately, in the general case, there isn't a good way to do that, short of having SCons evaluate its dependency graph twice, first to count the total and the second time to actually build the targets. This would be necessary because you can't know in advance which target(s) the user actually requested to be built. The entire build may consist of thousands of Nodes, for example, but maybe the user specifically requested that only a single object file be built.)

SCons, like most build tools, returns zero status to the shell on success and nonzero status on failure. Sometimes it's useful to give more information about the build status at the end of the run, for instance to print an informative message, send an email, or page the poor slob who broke the build.

SCons provides a GetBuildFailures method that you can use in a python atexit function to get a list of objects describing the actions that failed while attempting to build targets. There can be more than one if you're using -j. Here's a simple example:

import atexit

def print_build_failures():
    from SCons.Script import GetBuildFailures
    for bf in GetBuildFailures():
        print("%s failed: %s" % (bf.node, bf.errstr))
atexit.register(print_build_failures)
      

The atexit.register call registers print_build_failures as an atexit callback, to be called before SCons exits. When that function is called, it calls GetBuildFailures to fetch the list of failed objects. See the man page for the detailed contents of the returned objects; some of the more useful attributes are .node, .errstr, .filename, and .command. The filename is not necessarily the same file as the node; the node is the target that was being built when the error occurred, while the filenameis the file or dir that actually caused the error. Note: only call GetBuildFailures at the end of the build; calling it at any other time is undefined.

Here is a more complete example showing how to turn each element of GetBuildFailures into a string:

# Make the build fail if we pass fail=1 on the command line
if ARGUMENTS.get('fail', 0):
    Command('target', 'source', ['/bin/false'])

def bf_to_str(bf):
    """Convert an element of GetBuildFailures() to a string
    in a useful way."""
    import SCons.Errors
    if bf is None: # unknown targets product None in list
        return '(unknown tgt)'
    elif isinstance(bf, SCons.Errors.StopError):
        return str(bf)
    elif bf.node:
        return str(bf.node) + ': ' + bf.errstr
    elif bf.filename:
        return bf.filename + ': ' + bf.errstr
    return 'unknown failure: ' + bf.errstr
import atexit

def build_status():
    """Convert the build status to a 2-tuple, (status, msg)."""
    from SCons.Script import GetBuildFailures
    bf = GetBuildFailures()
    if bf:
        # bf is normally a list of build failures; if an element is None,
        # it's because of a target that scons doesn't know anything about.
        status = 'failed'
        failures_message = "\n".join(["Failed building %s" % bf_to_str(x)
                           for x in bf if x is not None])
    else:
        # if bf is None, the build completed successfully.
        status = 'ok'
        failures_message = ''
    return (status, failures_message)

def display_build_status():
    """Display the build status.  Called by atexit.
    Here you could do all kinds of complicated things."""
    status, failures_message = build_status()
    if status == 'failed':
       print("FAILED!!!!")  # could display alert, ring bell, etc.
    elif status == 'ok':
       print("Build succeeded.")
    print(failures_message)

atexit.register(display_build_status)
      

When this runs, you'll see the appropriate output:

% scons -Q
scons: `.' is up to date.
Build succeeded.
% scons -Q fail=1
scons: *** [target] Source `source' not found, needed by target `target'.
FAILED!!!!
Failed building target: Source `source' not found, needed by target `target'.

SCons has many command-line options that control its behavior. A SCons command-line option always begins with one or two - (hyphen) characters.

% scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
    ... [build output] ...
scons: done building targets.
% export SCONSFLAGS="-Q"
% scons
    ... [build output] ...

$ setenv SCONSFLAGS "-Q"
      

if not GetOption('help'):
    SConscript('src/SConscript', export='env')
      

import os
num_cpu = int(os.environ.get('NUM_CPU', 2))
SetOption('num_jobs', num_cpu)
print("running with -j %s"%GetOption('num_jobs'))
        

% scons -Q
running with -j 2
scons: `.' is up to date.

% export NUM_CPU="4"
% scons -Q
running with -j 4
scons: `.' is up to date.

% scons -Q -j 7
running with -j 7
scons: `.' is up to date.
% export NUM_CPU="4"
% scons -Q -j 3
running with -j 3
scons: `.' is up to date.

AddOption('--prefix',
          dest='prefix',
          type='string',
          nargs=1,
          action='store',
          metavar='DIR',
          help='installation prefix')

env = Environment(PREFIX = GetOption('prefix'))

installed_foo = env.Install('$PREFIX/usr/bin', 'foo.in')
Default(installed_foo)
        

% scons -Q -n
Install file: "foo.in" as "/usr/bin/foo.in"

% scons -Q -n --prefix=/tmp/install
Install file: "foo.in" as "/tmp/install/usr/bin/foo.in"

You may want to control various aspects of your build by allowing the user to specify variable=value values on the command line. For example, suppose you want users to be able to build a debug version of a program by running SCons as follows:

% scons -Q debug=1
    

SCons provides an ARGUMENTS dictionary that stores all of the variable=value assignments from the command line. This allows you to modify aspects of your build in response to specifications on the command line. (Note that unless you want to require that users always specify a variable, you probably want to use the Python ARGUMENTS.get() function, which allows you to specify a default value to be used if there is no specification on the command line.)

The following code sets the $CCFLAGS construction variable in response to the debug flag being set in the ARGUMENTS dictionary:

env = Environment()
debug = ARGUMENTS.get('debug', 0)
if int(debug):
    env.Append(CCFLAGS = '-g')
env.Program('prog.c')
       

This results in the -g compiler option being used when debug=1 is used on the command line:

% scons -Q debug=0
cc -o prog.o -c prog.c
cc -o prog prog.o
% scons -Q debug=0
scons: `.' is up to date.
% scons -Q debug=1
cc -o prog.o -c -g prog.c
cc -o prog prog.o
% scons -Q debug=1
scons: `.' is up to date.

Notice that SCons keeps track of the last values used to build the object files, and as a result correctly rebuilds the object and executable files only when the value of the debug argument has changed.

The ARGUMENTS dictionary has two minor drawbacks. First, because it is a dictionary, it can only store one value for each specified keyword, and thus only "remembers" the last setting for each keyword on the command line. This makes the ARGUMENTS dictionary inappropriate if users should be able to specify multiple values on the command line for a given keyword. Second, it does not preserve the order in which the variable settings were specified, which is a problem if you want the configuration to behave differently in response to the order in which the build variable settings were specified on the command line.

To accomodate these requirements, SCons provides an ARGLIST variable that gives you direct access to variable=value settings on the command line, in the exact order they were specified, and without removing any duplicate settings. Each element in the ARGLIST variable is itself a two-element list containing the keyword and the value of the setting, and you must loop through, or otherwise select from, the elements of ARGLIST to process the specific settings you want in whatever way is appropriate for your configuration. For example, the following code to let the user add to the CPPDEFINES construction variable by specifying multiple define= settings on the command line:

cppdefines = []
for key, value in ARGLIST:
    if key == 'define':
        cppdefines.append(value)
env = Environment(CPPDEFINES = cppdefines)
env.Object('prog.c')
       

Yields the following output:

% scons -Q define=FOO
cc -o prog.o -c -DFOO prog.c
% scons -Q define=FOO define=BAR
cc -o prog.o -c -DFOO -DBAR prog.c

Note that the ARGLIST and ARGUMENTS variables do not interfere with each other, but merely provide slightly different views into how the user specified variable=value settings on the command line. You can use both variables in the same SCons configuration. In general, the ARGUMENTS dictionary is more convenient to use, (since you can just fetch variable settings through a dictionary access), and the ARGLIST list is more flexible (since you can examine the specific order in which the user's command-line variabe settings).

vars = Variables(None, ARGUMENTS)
vars.Add('RELEASE', 'Set to 1 to build for release', 0)
env = Environment(variables = vars,
                  CPPDEFINES={'RELEASE_BUILD' : '${RELEASE}'})
env.Program(['foo.c', 'bar.c'])
        

% scons -Q RELEASE=1
cc -o bar.o -c -DRELEASE_BUILD=1 bar.c
cc -o foo.o -c -DRELEASE_BUILD=1 foo.c
cc -o foo foo.o bar.o

vars = Variables(None, ARGUMENTS)
vars.Add('RELEASE', 'Set to 1 to build for release', 0)
env = Environment(variables = vars)
Help(vars.GenerateHelpText(env))
        

% scons -Q -h

RELEASE: Set to 1 to build for release
    default: 0
    actual: 0

Use scons -H for help about command-line options.

vars = Variables('custom.py')
vars.Add('RELEASE', 'Set to 1 to build for release', 0)
env = Environment(variables = vars,
                  CPPDEFINES={'RELEASE_BUILD' : '${RELEASE}'})
env.Program(['foo.c', 'bar.c'])
Help(vars.GenerateHelpText(env))
        

RELEASE = 1
        

% scons -Q
cc -o bar.o -c -DRELEASE_BUILD=1 bar.c
cc -o foo.o -c -DRELEASE_BUILD=1 foo.c
cc -o foo foo.o bar.o

RELEASE = 0
        

% scons -Q
cc -o bar.o -c -DRELEASE_BUILD=0 bar.c
cc -o foo.o -c -DRELEASE_BUILD=0 foo.c
cc -o foo foo.o bar.o

vars = Variables('custom.py', ARGUMENTS)
      

vars = Variables('custom.py')
vars.Add(BoolVariable('RELEASE', 'Set to build for release', 0))
env = Environment(variables = vars,
                  CPPDEFINES={'RELEASE_BUILD' : '${RELEASE}'})
env.Program('foo.c')
          

% scons -Q RELEASE=yes foo.o
cc -o foo.o -c -DRELEASE_BUILD=True foo.c

% scons -Q RELEASE=t foo.o
cc -o foo.o -c -DRELEASE_BUILD=True foo.c

% scons -Q RELEASE=no foo.o
cc -o foo.o -c -DRELEASE_BUILD=False foo.c

% scons -Q RELEASE=f foo.o
cc -o foo.o -c -DRELEASE_BUILD=False foo.c

% scons -Q RELEASE=bad_value foo.o

scons: *** Error converting option: RELEASE
Invalid value for boolean option: bad_value
File "/home/my/project/SConstruct", line 4, in <module>

vars = Variables('custom.py')
vars.Add(EnumVariable('COLOR', 'Set background color', 'red',
                    allowed_values=('red', 'green', 'blue')))
env = Environment(variables = vars,
                  CPPDEFINES={'COLOR' : '"${COLOR}"'})
env.Program('foo.c')
          

% scons -Q COLOR=red foo.o
cc -o foo.o -c -DCOLOR="red" foo.c
% scons -Q COLOR=blue foo.o
cc -o foo.o -c -DCOLOR="blue" foo.c
% scons -Q COLOR=green foo.o
cc -o foo.o -c -DCOLOR="green" foo.c

% scons -Q COLOR=magenta foo.o

scons: *** Invalid value for option COLOR: magenta.  Valid values are: ('red', 'green', 'blue')
File "/home/my/project/SConstruct", line 5, in <module>

vars = Variables('custom.py')
vars.Add(EnumVariable('COLOR', 'Set background color', 'red',
                    allowed_values=('red', 'green', 'blue'),
                    map={'navy':'blue'}))
env = Environment(variables = vars,
                  CPPDEFINES={'COLOR' : '"${COLOR}"'})
env.Program('foo.c')
          

% scons -Q COLOR=navy foo.o
cc -o foo.o -c -DCOLOR="blue" foo.c

% scons -Q COLOR=Red foo.o

scons: *** Invalid value for option COLOR: Red.  Valid values are: ('red', 'green', 'blue')
File "/home/my/project/SConstruct", line 5, in <module>
% scons -Q COLOR=BLUE foo.o

scons: *** Invalid value for option COLOR: BLUE.  Valid values are: ('red', 'green', 'blue')
File "/home/my/project/SConstruct", line 5, in <module>
% scons -Q COLOR=nAvY foo.o

scons: *** Invalid value for option COLOR: nAvY.  Valid values are: ('red', 'green', 'blue')
File "/home/my/project/SConstruct", line 5, in <module>

vars = Variables('custom.py')
vars.Add(EnumVariable('COLOR', 'Set background color', 'red',
                    allowed_values=('red', 'green', 'blue'),
                    map={'navy':'blue'},
                    ignorecase=1))
env = Environment(variables = vars,
                  CPPDEFINES={'COLOR' : '"${COLOR}"'})
env.Program('foo.c')
          

% scons -Q COLOR=Red foo.o
cc -o foo.o -c -DCOLOR="Red" foo.c
% scons -Q COLOR=BLUE foo.o
cc -o foo.o -c -DCOLOR="BLUE" foo.c
% scons -Q COLOR=nAvY foo.o
cc -o foo.o -c -DCOLOR="blue" foo.c
% scons -Q COLOR=green foo.o
cc -o foo.o -c -DCOLOR="green" foo.c

vars = Variables('custom.py')
vars.Add(EnumVariable('COLOR', 'Set background color', 'red',
                    allowed_values=('red', 'green', 'blue'),
                    map={'navy':'blue'},
                    ignorecase=2))
env = Environment(variables = vars,
                  CPPDEFINES={'COLOR' : '"${COLOR}"'})
env.Program('foo.c')
          

% scons -Q COLOR=Red foo.o
cc -o foo.o -c -DCOLOR="red" foo.c
% scons -Q COLOR=nAvY foo.o
cc -o foo.o -c -DCOLOR="blue" foo.c
% scons -Q COLOR=GREEN foo.o
cc -o foo.o -c -DCOLOR="green" foo.c

vars = Variables('custom.py')
vars.Add(ListVariable('COLORS', 'List of colors', 0,
                    ['red', 'green', 'blue']))
env = Environment(variables = vars,
                  CPPDEFINES={'COLORS' : '"${COLORS}"'})
env.Program('foo.c')
          

% scons -Q COLORS=red,blue foo.o
cc -o foo.o -c -DCOLORS="red blue" foo.c
% scons -Q COLORS=blue,green,red foo.o
cc -o foo.o -c -DCOLORS="blue green red" foo.c

% scons -Q COLORS=all foo.o
cc -o foo.o -c -DCOLORS="red green blue" foo.c
% scons -Q COLORS=none foo.o
cc -o foo.o -c -DCOLORS="" foo.c

% scons -Q COLORS=magenta foo.o

scons: *** Error converting option: COLORS
Invalid value(s) for option: magenta
File "/home/my/project/SConstruct", line 5, in <module>

vars = Variables('custom.py')
vars.Add(PathVariable('CONFIG',
                    'Path to configuration file',
                    '/etc/my_config'))
env = Environment(variables = vars,
                  CPPDEFINES={'CONFIG_FILE' : '"$CONFIG"'})
env.Program('foo.c')
          

% scons -Q foo.o
cc -o foo.o -c -DCONFIG_FILE="/etc/my_config" foo.c
% scons -Q CONFIG=/usr/local/etc/other_config foo.o
scons: `foo.o' is up to date.

% scons -Q CONFIG=/does/not/exist foo.o

scons: *** Path for option CONFIG does not exist: /does/not/exist
File "/home/my/project/SConstruct", line 6, in <module>

vars = Variables('custom.py')
vars.Add(PathVariable('CONFIG',
                    'Path to configuration file',
                    '/etc/my_config',
                    PathVariable.PathIsFile))
env = Environment(variables = vars,
                  CPPDEFINES={'CONFIG_FILE' : '"$CONFIG"'})
env.Program('foo.c')
          

vars = Variables('custom.py')
vars.Add(PathVariable('DBDIR',
                    'Path to database directory',
                    '/var/my_dbdir',
                    PathVariable.PathIsDir))
env = Environment(variables = vars,
                  CPPDEFINES={'DBDIR' : '"$DBDIR"'})
env.Program('foo.c')
          

vars = Variables('custom.py')
vars.Add(PathVariable('DBDIR',
                    'Path to database directory',
                    '/var/my_dbdir',
                    PathVariable.PathIsDirCreate))
env = Environment(variables = vars,
                  CPPDEFINES={'DBDIR' : '"$DBDIR"'})
env.Program('foo.c')
          

vars = Variables('custom.py')
vars.Add(PathVariable('OUTPUT',
                    'Path to output file or directory',
                    None,
                    PathVariable.PathAccept))
env = Environment(variables = vars,
                  CPPDEFINES={'OUTPUT' : '"$OUTPUT"'})
env.Program('foo.c')
          

vars = Variables('custom.py')
vars.Add(PackageVariable('PACKAGE',
                       'Location package',
                       '/opt/location'))
env = Environment(variables = vars,
                  CPPDEFINES={'PACKAGE' : '"$PACKAGE"'})
env.Program('foo.c')
          

% scons -Q foo.o
cc -o foo.o -c -DPACKAGE="/opt/location" foo.c
% scons -Q PACKAGE=/usr/local/location foo.o
cc -o foo.o -c -DPACKAGE="/usr/local/location" foo.c
% scons -Q PACKAGE=yes foo.o
cc -o foo.o -c -DPACKAGE="True" foo.c
% scons -Q PACKAGE=no foo.o
cc -o foo.o -c -DPACKAGE="False" foo.c

vars = Variables()
vars.AddVariables(
    ('RELEASE', 'Set to 1 to build for release', 0),
    ('CONFIG', 'Configuration file', '/etc/my_config'),
    BoolVariable('warnings', 'compilation with -Wall and similiar', 1),
    EnumVariable('debug', 'debug output and symbols', 'no',
               allowed_values=('yes', 'no', 'full'),
               map={}, ignorecase=0),  # case sensitive
    ListVariable('shared',
               'libraries to build as shared libraries',
               'all',
               names = list_of_libs),
    PackageVariable('x11',
                  'use X11 installed here (yes = search some places)',
                  'yes'),
    PathVariable('qtdir', 'where the root of Qt is installed', qtdir),
)
        

vars = Variables(None)
vars.Add('RELEASE', 'Set to 1 to build for release', 0)
env = Environment(variables = vars,
                  CPPDEFINES={'RELEASE_BUILD' : '${RELEASE}'})
unknown = vars.UnknownVariables()
if unknown:
    print("Unknown variables: %s"%unknown.keys())
    Exit(1)
env.Program('foo.c')
        

% scons -Q NOT_KNOWN=foo
Unknown variables: ['NOT_KNOWN']

You can install multiple files into a directory simply by calling the Install function multiple times:

env = Environment()
hello = env.Program('hello.c')
goodbye = env.Program('goodbye.c')
env.Install('/usr/bin', hello)
env.Install('/usr/bin', goodbye)
env.Alias('install', '/usr/bin')
      

Or, more succinctly, listing the multiple input files in a list (just like you can do with any other builder):

env = Environment()
hello = env.Program('hello.c')
goodbye = env.Program('goodbye.c')
env.Install('/usr/bin', [hello, goodbye])
env.Alias('install', '/usr/bin')
    

Either of these two examples yields:

% scons -Q install
cc -o goodbye.o -c goodbye.c
cc -o goodbye goodbye.o
Install file: "goodbye" as "/usr/bin/goodbye"
cc -o hello.o -c hello.c
cc -o hello hello.o
Install file: "hello" as "/usr/bin/hello"

The Install method preserves the name of the file when it is copied into the destination directory. If you need to change the name of the file when you copy it, use the InstallAs function:

env = Environment()
hello = env.Program('hello.c')
env.InstallAs('/usr/bin/hello-new', hello)
env.Alias('install', '/usr/bin')
      

This installs the hello program with the name hello-new as follows:

% scons -Q install
cc -o hello.o -c hello.c
cc -o hello hello.o
Install file: "hello" as "/usr/bin/hello-new"

Lastly, if you have multiple files that all need to be installed with different file names, you can either call the InstallAs function multiple times, or as a shorthand, you can supply same-length lists for both the target and source arguments:

env = Environment()
hello = env.Program('hello.c')
goodbye = env.Program('goodbye.c')
env.InstallAs(['/usr/bin/hello-new',
               '/usr/bin/goodbye-new'],
               [hello, goodbye])
env.Alias('install', '/usr/bin')
      

In this case, the InstallAs function loops through both lists simultaneously, and copies each source file into its corresponding target file name:

% scons -Q install
cc -o goodbye.o -c goodbye.c
cc -o goodbye goodbye.o
Install file: "goodbye" as "/usr/bin/goodbye-new"
cc -o hello.o -c hello.c
cc -o hello hello.o
Install file: "hello" as "/usr/bin/hello-new"

Suppose you want to arrange to make a copy of a file, and don't have a suitable pre-existing builder. ^[4] One way would be to use the Copy action factory in conjunction with the Command builder:

Command("file.out", "file.in", Copy("$TARGET", "$SOURCE"))
      

Notice that the action returned by the Copy factory will expand the $TARGET and $SOURCE strings at the time file.out is built, and that the order of the arguments is the same as that of a builder itself--that is, target first, followed by source:

% scons -Q
Copy("file.out", "file.in")

You can, of course, name a file explicitly instead of using $TARGET or $SOURCE:

Command("file.out", [], Copy("$TARGET", "file.in"))
      

Which executes as:

% scons -Q
Copy("file.out", "file.in")

The usefulness of the Copy factory becomes more apparent when you use it in a list of actions passed to the Command builder. For example, suppose you needed to run a file through a utility that only modifies files in-place, and can't "pipe" input to output. One solution is to copy the source file to a temporary file name, run the utility, and then copy the modified temporary file to the target, which the Copy factory makes extremely easy:

Command("file.out", "file.in",
        [
          Copy("tempfile", "$SOURCE"),
          "modify tempfile",
          Copy("$TARGET", "tempfile"),
        ])
      

The output then looks like:

% scons -Q
Copy("tempfile", "file.in")
modify tempfile
Copy("file.out", "tempfile")

The Copy factory has a third optional argument which controls how symlinks are copied.

# Symbolic link shallow copied as a new symbolic link:
Command("LinkIn", "LinkOut", Copy("$TARGET", "$SOURCE"[, True]))

# Symbolic link target copied as a file or directory:
Command("LinkIn", "FileOrDirectoryOut", Copy("$TARGET", "$SOURCE", False))
      

If you need to delete a file, then the Delete factory can be used in much the same way as the Copy factory. For example, if we want to make sure that the temporary file in our last example doesn't exist before we copy to it, we could add Delete to the beginning of the command list:

Command("file.out", "file.in",
        [
          Delete("tempfile"),
          Copy("tempfile", "$SOURCE"),
          "modify tempfile",
          Copy("$TARGET", "tempfile"),
        ])
      

Which then executes as follows:

% scons -Q
Delete("tempfile")
Copy("tempfile", "file.in")
modify tempfile
Copy("file.out", "tempfile")

Of course, like all of these Action factories, the Delete factory also expands $TARGET and $SOURCE variables appropriately. For example:

Command("file.out", "file.in",
        [
          Delete("$TARGET"),
          Copy("$TARGET", "$SOURCE")
        ])
      

Executes as:

% scons -Q
Delete("file.out")
Copy("file.out", "file.in")

Note, however, that you typically don't need to call the Delete factory explicitly in this way; by default, SCons deletes its target(s) for you before executing any action.

One word of caution about using the Delete factory: it has the same variable expansions available as any other factory, including the $SOURCE variable. Specifying Delete("$SOURCE") is not something you usually want to do!

The Move factory allows you to rename a file or directory. For example, if we don't want to copy the temporary file, we could use:

Command("file.out", "file.in",
        [
          Copy("tempfile", "$SOURCE"),
          "modify tempfile",
          Move("$TARGET", "tempfile"),
        ])
      

Which would execute as:

% scons -Q
Copy("tempfile", "file.in")
modify tempfile
Move("file.out", "tempfile")

If you just need to update the recorded modification time for a file, use the Touch factory:

Command("file.out", "file.in",
        [
          Copy("$TARGET", "$SOURCE"),
          Touch("$TARGET"),
        ])
      

Which executes as:

% scons -Q
Copy("file.out", "file.in")
Touch("file.out")

If you need to create a directory, use the Mkdir factory. For example, if we need to process a file in a temporary directory in which the processing tool will create other files that we don't care about, you could use:

Command("file.out", "file.in",
        [
          Delete("tempdir"),
          Mkdir("tempdir"),
          Copy("tempdir/${SOURCE.file}", "$SOURCE"),
          "process tempdir",
          Move("$TARGET", "tempdir/output_file"),
          Delete("tempdir"),
        ])
      

Which executes as:

% scons -Q
Delete("tempdir")
Mkdir("tempdir")
Copy("tempdir/file.in", "file.in")
process tempdir
Move("file.out", "tempdir/output_file")
scons: *** [file.out] tempdir/output_file: No such file or directory

To change permissions on a file or directory, use the Chmod factory. The permission argument uses POSIX-style permission bits and should typically be expressed as an octal, not decimal, number:

Command("file.out", "file.in",
        [
          Copy("$TARGET", "$SOURCE"),
          Chmod("$TARGET", 0755),
        ])
      

Which executes:

% scons -Q
Copy("file.out", "file.in")
Chmod("file.out", 0755)

We've been showing you how to use Action factories in the Command function. You can also execute an Action returned by a factory (or actually, any Action) at the time the SConscript file is read by using the Execute function. For example, if we need to make sure that a directory exists before we build any targets,

Execute(Mkdir('/tmp/my_temp_directory'))
      

Notice that this will create the directory while the SConscript file is being read:

% scons
scons: Reading SConscript files ...
Mkdir("/tmp/my_temp_directory")
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

If you're familiar with Python, you may wonder why you would want to use this instead of just calling the native Python os.mkdir() function. The advantage here is that the Mkdir action will behave appropriately if the user specifies the SCons -n or -q options--that is, it will print the action but not actually make the directory when -n is specified, or make the directory but not print the action when -q is specified.

The Execute function returns the exit status or return value of the underlying action being executed. It will also print an error message if the action fails and returns a non-zero value. SCons will not, however, actually stop the build if the action fails. If you want the build to stop in response to a failure in an action called by Execute, you must do so by explicitly checking the return value and calling the Exit function (or a Python equivalent):

if Execute(Mkdir('/tmp/my_temp_directory')):
    # A problem occurred while making the temp directory.
    Exit(1)
    

By default, SCons removes targets before building them. Sometimes, however, this is not what you want. For example, you may want to update a library incrementally, not by having it deleted and then rebuilt from all of the constituent object files. In such cases, you can use the Precious method to prevent SCons from removing the target before it is built:

  env = Environment(RANLIBCOM='')
  lib = env.Library('foo', ['f1.c', 'f2.c', 'f3.c'])
  env.Precious(lib)
      

Although the output doesn't look any different, SCons does not, in fact, delete the target library before rebuilding it:

% scons -Q
cc -o f1.o -c f1.c
cc -o f2.o -c f2.c
cc -o f3.o -c f3.c
ar rc libfoo.a f1.o f2.o f3.o

SCons will, however, still delete files marked as Precious when the -c option is used.

By default, SCons removes all built targets when invoked with the -c option to clean a source tree of built targets. Sometimes, however, this is not what you want. For example, you may want to remove only intermediate generated files (such as object files), but leave the final targets (the libraries) untouched. In such cases, you can use the NoClean method to prevent SCons from removing a target during a clean:

env = Environment(RANLIBCOM='')
lib = env.Library('foo', ['f1.c', 'f2.c', 'f3.c'])
env.NoClean(lib)
      

Notice that the libfoo.a is not listed as a removed file:

% scons -Q
cc -o f1.o -c f1.c
cc -o f2.o -c f2.c
cc -o f3.o -c f3.c
ar rc libfoo.a f1.o f2.o f3.o
% scons -c
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Cleaning targets ...
Removed f1.o
Removed f2.o
Removed f3.o
scons: done cleaning targets.

There may be additional files that you want removed when the -c option is used, but which SCons doesn't know about because they're not normal target files. For example, perhaps a command you invoke creates a log file as part of building the target file you want. You would like the log file cleaned, but you don't want to have to teach SCons that the command "builds" two files.

You can use the Clean function to arrange for additional files to be removed when the -c option is used. Notice, however, that the Clean function takes two arguments, and the second argument is the name of the additional file you want cleaned (foo.log in this example):

t = Command('foo.out', 'foo.in', 'build -o $TARGET $SOURCE')
Clean(t, 'foo.log')
      

The first argument is the target with which you want the cleaning of this additional file associated. In the above example, we've used the return value from the Command function, which represents the foo.out target. Now whenever the foo.out target is cleaned by the -c option, the foo.log file will be removed as well:

% scons -Q
build -o foo.out foo.in
% scons -Q -c
Removed foo.out
Removed foo.log

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.

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.

If you need to use a file from another directory, it's sometimes more convenient to specify the path to a file in another directory from the top-level SConstruct directory, even when you're using that file in a subsidiary SConscript file in a subdirectory. You can tell SCons to interpret a path name as relative to the top-level SConstruct directory, not the local directory of the SConscript file, by appending a # (hash mark) to the beginning of the path name:

env = Environment()
env.Program('prog', ['main.c', '#lib/foo1.c', 'foo2.c'])
       

In this example, the lib directory is directly underneath the top-level SConstruct directory. If the above SConscript file is in a subdirectory named src/prog, the output would look like:

% scons -Q
cc -o lib/foo1.o -c lib/foo1.c
cc -o src/prog/foo2.o -c src/prog/foo2.c
cc -o src/prog/main.o -c src/prog/main.c
cc -o src/prog/prog src/prog/main.o lib/foo1.o src/prog/foo2.o

(Notice that the lib/foo1.o object file is built in the same directory as its source file. See Chapter 15, Separating Source and Build Directories, below, for information about how to build the object file in a different subdirectory.)

Of course, you can always specify an absolute path name for a file--for example:

env = Environment()
env.Program('prog', ['main.c', '/usr/joe/lib/foo1.c', 'foo2.c'])
       

Which, when executed, would yield:

% scons -Q
cc -o src/prog/foo2.o -c src/prog/foo2.c
cc -o src/prog/main.o -c src/prog/main.c
cc -o /usr/joe/lib/foo1.o -c /usr/joe/lib/foo1.c
cc -o src/prog/prog src/prog/main.o /usr/joe/lib/foo1.o src/prog/foo2.o

(As was the case with top-relative path names, notice that the /usr/joe/lib/foo1.o object file is built in the same directory as its source file. See Chapter 15, Separating Source and Build Directories, below, for information about how to build the object file in a different subdirectory.)

In the previous example, each of the subsidiary SConscript files created its own construction environment by calling Environment separately. This obviously works fine, but if each program must be built with the same construction variables, it's cumbersome and error-prone to initialize separate construction environments in the same way over and over in each subsidiary SConscript file.

SCons supports the ability to export variables from a parent SConscript file to its subsidiary SConscript files, which allows you to share common initialized values throughout your build hierarchy.

env = Environment()
Export('env')
      

env = Environment()
debug = ARGUMENTS['debug']
Export('env', 'debug')
      

Export('env debug')
      

SConscript('src/SConscript', 'env')
      

SConscript('src/SConscript', exports='env')
      

SConscript(['src1/SConscript',
            'src2/SConscript'], exports='env')
      

Import('env')
env.Program('prog', ['prog.c'])
      

Import('env', 'debug')
env = env.Clone(DEBUG = debug)
env.Program('prog', ['prog.c'])
      

Import('env debug')
env = env.Clone(DEBUG = debug)
env.Program('prog', ['prog.c'])
      

Import('*')
env = env.Clone(DEBUG = debug)
env.Program('prog', ['prog.c'])
      

env = Environment()
Export('env')
objs = []
for subdir in ['foo', 'bar']:
    o = SConscript('%s/SConscript' % subdir)
    objs.append(o)
env.Library('prog', objs)
        

Import('env')
obj = env.Object('foo.c')
Return('obj')
        

% scons -Q
cc -o bar/bar.o -c bar/bar.c
cc -o foo/foo.o -c foo/foo.c
ar rc libprog.a foo/foo.o bar/bar.o
ranlib libprog.a

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:

SConscript('src/SConscript', variant_dir='build')
      

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.

SCons duplicates source files in variant directory trees because it's the most straightforward way to guarantee a correct build regardless of include-file directory paths, relative references between files, or tool support for putting files in different locations, and the SCons philosophy is to, by default, guarantee a correct build in all cases.

The most direct reason to duplicate source files in variant directories is simply that some tools (mostly older versions) are written to only build their output files in the same directory as the source files. In this case, the choices are either to build the output file in the source directory and move it to the variant directory, or to duplicate the source files in the variant directory.

Additionally, relative references between files can cause problems if we don't just duplicate the hierarchy of source files in the variant directory. You can see this at work in use of the C preprocessor #include mechanism with double quotes, not angle brackets:

#include "file.h"
    

The de facto standard behavior for most C compilers in this case is to first look in the same directory as the source file that contains the #include line, then to look in the directories in the preprocessor search path. Add to this that the SCons implementation of support for code repositories (described below) means not all of the files will be found in the same directory hierarchy, and the simplest way to make sure that the right include file is found is to duplicate the source files into the variant directory, which provides a correct build regardless of the original location(s) of the source files.

Although source-file duplication guarantees a correct build even in these end-cases, it can usually be safely disabled. The next section describes how you can disable the duplication of source files in the variant directory.

In most cases and with most tool sets, SCons can place its target files in a build subdirectory without duplicating the source files and everything will work just fine. You can disable the default SCons behavior by specifying duplicate=0 when you call the SConscript function:

SConscript('src/SConscript', variant_dir='build', duplicate=0)
    

When this flag is specified, SCons uses the variant directory like most people expect--that is, the output files are placed in the variant directory while the source files stay in the source directory:

% ls src
SConscript
hello.c
% scons -Q
cc -c src/hello.c -o build/hello.o
cc -o build/hello build/hello.o
% ls build
hello
hello.o
    

Use the VariantDir function to establish that target files should be built in a separate directory from the source files:

VariantDir('build', 'src')
env = Environment()
env.Program('build/hello.c')
      

Note that when you're not using an SConscript file in the src subdirectory, you must actually specify that the program must be built from the build/hello.c file that SCons will duplicate in the build subdirectory.

When using the VariantDir function directly, SCons still duplicates the source files in the variant directory by default:

% ls src
hello.c
% scons -Q
cc -o build/hello.o -c build/hello.c
cc -o build/hello build/hello.o
% ls build
hello  hello.c  hello.o

You can specify the same duplicate=0 argument that you can specify for an SConscript call:

VariantDir('build', 'src', duplicate=0)
env = Environment()
env.Program('build/hello.c')
      

In which case SCons will disable duplication of the source files:

% ls src
hello.c
% scons -Q
cc -o build/hello.o -c src/hello.c
cc -o build/hello build/hello.o
% ls build
hello  hello.o

Even when using the VariantDir function, it's much more natural to use it with a subsidiary SConscript file. For example, if the src/SConscript looks like this:

env = Environment()
env.Program('hello.c')
      

Then our SConstruct file could look like:

VariantDir('build', 'src')
SConscript('build/SConscript')
      

Yielding the following output:

% 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

Notice that this is completely equivalent to the use of SConscript that we learned about in the previous section.

The Glob file name pattern matching function works just as usual when using VariantDir. For example, if the src/SConscript looks like this:

env = Environment()
env.Program('hello', Glob('*.c'))
      

Then with the same SConstruct file as in the previous section, and source files f1.c and f2.c in src, we would see the following output:

% ls src
SConscript  f1.c  f2.c  f2.h
% scons -Q
cc -o build/f1.o -c build/f1.c
cc -o build/f2.o -c build/f2.c
cc -o build/hello build/f1.o build/f2.o
% ls build
SConscript  f1.c  f1.o  f2.c  f2.h  f2.o  hello

The Glob function returns Nodes in the build/ tree, as you'd expect.

To follow examples provided in this chapter set up your operating system to support two or more languages. In following examples we use locales en_US, de_DE, and pl_PL.

Ensure, that you have GNU gettext utilities installed on your system.

To edit translation files you may wish to install poedit editor.

Let's start with a very simple project, the "Hello world" program for example

/* hello.c */
#include <stdio.h>
int main(int argc, char* argv[])
{
  printf("Hello world\n");
  return 0;
}
    

Prepare a SConstruct to compile the program as usual.

# SConstruct
env = Environment()
hello = Program(["hello.c"])
    

Now we'll convert the project to a multi-lingual one. If you don't already have GNU gettext utilities installed, install them from your preffered package repository, or download from http://ftp.gnu.org/gnu/gettext/. For the purpose of this example, you should have following three locales installed on your system: en_US, de_DE and pl_PL. On debian, for example, you may enable certain locales through dpkg-reconfigure locales.

First prepare the hello.c program for internationalization. Change the previous code so it reads as follows:

/* hello.c */
#include <stdio.h>
#include <libintl.h>
#include <locale.h>
int main(int argc, char* argv[])
{
  bindtextdomain("hello", "locale");
  setlocale(LC_ALL, "");
  textdomain("hello");
  printf(gettext("Hello world\n"));
  return 0;
}
    

Detailed recipes for such conversion can be found at http://www.gnu.org/software/gettext/manual/gettext.html#Sources. The gettext("...") has two purposes. First, it marks messages for the xgettext(1) program, which we will use to extract from the sources the messages for localization. Second, it calls the gettext library internals to translate the message at runtime.

Now we shall instruct SCons how to generate and maintain translation files. For that, use the Translate builder and MOFiles builder. The first one takes source files, extracts internationalized messages from them, creates so-called POT file (translation template), and then creates PO translation files, one for each requested language. Later, during the development lifecycle, the builder keeps all these files up-to date. The MOFiles builder compiles the PO files to binary form. Then install the MO files under directory called locale.

The completed SConstruct is as follows:

# SConstruct
env = Environment( tools = ['default', 'gettext'] )
hello = env.Program(["hello.c"])
env['XGETTEXTFLAGS'] = [
  '--package-name=%s' % 'hello',
  '--package-version=%s' % '1.0',
]
po = env.Translate(["pl","en", "de"], ["hello.c"], POAUTOINIT = 1)
mo = env.MOFiles(po)
InstallAs(["locale/en/LC_MESSAGES/hello.mo"], ["en.mo"])
InstallAs(["locale/pl/LC_MESSAGES/hello.mo"], ["pl.mo"])
InstallAs(["locale/de/LC_MESSAGES/hello.mo"], ["de.mo"])
    

Generate the translation files with scons po-update. You should see the output from SCons simillar to this:

user@host:$ scons po-update
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Entering '/home/ptomulik/projects/tmp'
xgettext --package-name=hello --package-version=1.0 -o - hello.c
Leaving '/home/ptomulik/projects/tmp'
Writting 'messages.pot' (new file)
msginit --no-translator -l pl -i messages.pot -o pl.po
Created pl.po.
msginit --no-translator -l en -i messages.pot -o en.po
Created en.po.
msginit --no-translator -l de -i messages.pot -o de.po
Created de.po.
scons: done building targets.
    

If everything is right, you should see following new files.

user@host:$ ls *.po*
de.po  en.po  messages.pot  pl.po
    

Open en.po in poedit and provide the English translation to message "Hello world\n". Do the same for de.po (deutsch) and pl.po (polish). Let the translations be, for example:

Now compile the project by executing scons. The output should be similar to this:

user@host:$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
msgfmt -c -o de.mo de.po
msgfmt -c -o en.mo en.po
gcc -o hello.o -c hello.c
gcc -o hello hello.o
Install file: "de.mo" as "locale/de/LC_MESSAGES/hello.mo"
Install file: "en.mo" as "locale/en/LC_MESSAGES/hello.mo"
msgfmt -c -o pl.mo pl.po
Install file: "pl.mo" as "locale/pl/LC_MESSAGES/hello.mo"
scons: done building targets.
    

SCons automatically compiled the PO files to binary format MO, and the InstallAs lines installed these files under locale folder.

Your program should be now ready. You may try it as follows (linux):

user@host:$ LANG=en_US.UTF-8 ./hello
Welcome to beautiful world
    

user@host:$ LANG=de_DE.UTF-8 ./hello
Hallo Welt
    

user@host:$ LANG=pl_PL.UTF-8 ./hello
Witaj swiecie
    

To demonstrate the further life of translation files, let's change Polish translation (poedit pl.po) to "Witaj drogi swiecie\n". Run scons to see how scons reacts to this

user@host:$scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
msgfmt -c -o pl.mo pl.po
Install file: "pl.mo" as "locale/pl/LC_MESSAGES/hello.mo"
scons: done building targets.
    

Now, open hello.c and add another one printf line with new message.

/* hello.c */
#include <stdio.h>
#include <libintl.h>
#include <locale.h>
int main(int argc, char* argv[])
{
  bindtextdomain("hello", "locale");
  setlocale(LC_ALL, "");
  textdomain("hello");
  printf(gettext("Hello world\n"));
  printf(gettext("and good bye\n"));
  return 0;
}
    

Compile project with scons. This time, the msgmerge(1) program is used by SCons to update PO file. The output from compilation is like:

user@host:$scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Entering '/home/ptomulik/projects/tmp'
xgettext --package-name=hello --package-version=1.0 -o - hello.c
Leaving '/home/ptomulik/projects/tmp'
Writting 'messages.pot' (messages in file were outdated)
msgmerge --update de.po messages.pot
... done.
msgfmt -c -o de.mo de.po
msgmerge --update en.po messages.pot
... done.
msgfmt -c -o en.mo en.po
gcc -o hello.o -c hello.c
gcc -o hello hello.o
Install file: "de.mo" as "locale/de/LC_MESSAGES/hello.mo"
Install file: "en.mo" as "locale/en/LC_MESSAGES/hello.mo"
msgmerge --update pl.po messages.pot
... done.
msgfmt -c -o pl.mo pl.po
Install file: "pl.mo" as "locale/pl/LC_MESSAGES/hello.mo"
scons: done building targets.
    

The next example demonstrates what happens if we change the source code in such way that the internationalized messages do not change. The answer is that none of translation files (POT, PO) are touched (i.e. no content changes, no creation/modification time changed and so on). Let's append another line to the program (after the last printf), so its code becomes:

/* hello.c */
#include <stdio.h>
#include <libintl.h>
#include <locale.h>
int main(int argc, char* argv[])
{
  bindtextdomain("hello", "locale");
  setlocale(LC_ALL, "");
  textdomain("hello");
  printf(gettext("Hello world\n"));
  printf(gettext("and good bye\n"));
  printf("----------------\n");
  return a;
}
    

Compile the project. You'll see on your screen

user@host:$scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Entering '/home/ptomulik/projects/tmp'
xgettext --package-name=hello --package-version=1.0 -o - hello.c
Leaving '/home/ptomulik/projects/tmp'
Not writting 'messages.pot' (messages in file found to be up-to-date)
gcc -o hello.o -c hello.c
gcc -o hello hello.o
scons: done building targets.
    

As you see, the internationalized messages ditn't change, so the POT and the rest of translation files have not even been touched.

The simplest Builder to create is one that executes an external command. For example, if we want to build an output file by running the contents of the input file through a command named foobuild, creating that Builder might look like:

bld = Builder(action = 'foobuild < $SOURCE > $TARGET')
    

All the above line does is create a free-standing Builder object. The next section will show us how to actually use it.

A Builder object isn't useful until it's attached to a construction environment so that we can call it to arrange for files to be built. This is done through the $BUILDERS construction variable in an environment. The $BUILDERS variable is a Python dictionary that maps the names by which you want to call various Builder objects to the objects themselves. For example, if we want to call the Builder we just defined by the name Foo, our SConstruct file might look like:

bld = Builder(action = 'foobuild < $SOURCE > $TARGET')
env = Environment(BUILDERS = {'Foo' : bld})
    

With the Builder attached to our construction environment with the name Foo, we can now actually call it like so:

env.Foo('file.foo', 'file.input')
    

Then when we run SCons it looks like:

% scons -Q
foobuild < file.input > file.foo

Note, however, that the default $BUILDERS variable in a construction environment comes with a default set of Builder objects already defined: Program, Library, etc. And when we explicitly set the $BUILDERS variable when we create the construction environment, the default Builders are no longer part of the environment:

bld = Builder(action = 'foobuild < $SOURCE > $TARGET')
env = Environment(BUILDERS = {'Foo' : bld})
env.Foo('file.foo', 'file.input')
env.Program('hello.c')
       

% scons -Q
AttributeError: 'SConsEnvironment' object has no attribute 'Program':
  File "/home/my/project/SConstruct", line 4:
    env.Program('hello.c')

To be able to use both our own defined Builder objects and the default Builder objects in the same construction environment, you can either add to the $BUILDERS variable using the Append function:

env = Environment()
bld = Builder(action = 'foobuild < $SOURCE > $TARGET')
env.Append(BUILDERS = {'Foo' : bld})
env.Foo('file.foo', 'file.input')
env.Program('hello.c')
    

Or you can explicitly set the appropriately-named key in the $BUILDERS dictionary:

env = Environment()
bld = Builder(action = 'foobuild < $SOURCE > $TARGET')
env['BUILDERS']['Foo'] = bld
env.Foo('file.foo', 'file.input')
env.Program('hello.c')
    

Either way, the same construction environment can then use both the newly-defined Foo Builder and the default Program Builder:

% scons -Q
foobuild < file.input > file.foo
cc -o hello.o -c hello.c
cc -o hello hello.o

By supplying additional information when you create a Builder, you can let SCons add appropriate file suffixes to the target and/or the source file. For example, rather than having to specify explicitly that you want the Foo Builder to build the file.foo target file from the file.input source file, you can give the .foo and .input suffixes to the Builder, making for more compact and readable calls to the Foo Builder:

bld = Builder(action = 'foobuild < $SOURCE > $TARGET',
              suffix = '.foo',
              src_suffix = '.input')
env = Environment(BUILDERS = {'Foo' : bld})
env.Foo('file1')
env.Foo('file2')
    

% scons -Q
foobuild < file1.input > file1.foo
foobuild < file2.input > file2.foo

You can also supply a prefix keyword argument if it's appropriate to have SCons append a prefix to the beginning of target file names.

In SCons, you don't have to call an external command to build a file. You can, instead, define a Python function that a Builder object can invoke to build your target file (or files). Such a builder function definition looks like:

def build_function(target, source, env):
    # Code to build "target" from "source"
    return None
    

The arguments of a builder function are:

The builder function must return a 0 or None value if the target(s) are built successfully. The builder function may raise an exception or return any non-zero value to indicate that the build is unsuccessful.

Once you've defined the Python function that will build your target file, defining a Builder object for it is as simple as specifying the name of the function, instead of an external command, as the Builder's action argument:

def build_function(target, source, env):
    # Code to build "target" from "source"
    return None
bld = Builder(action = build_function,
              suffix = '.foo',
              src_suffix = '.input')
env = Environment(BUILDERS = {'Foo' : bld})
env.Foo('file')
       

And notice that the output changes slightly, reflecting the fact that a Python function, not an external command, is now called to build the target file:

% scons -Q
build_function(["file.foo"], ["file.input"])

SCons Builder objects can create an action "on the fly" by using a function called a generator. This provides a great deal of flexibility to construct just the right list of commands to build your target. A generator looks like:

def generate_actions(source, target, env, for_signature):
    return 'foobuild < %s > %s' % (target[0], source[0])
    

The arguments of a generator are:

The generator must return a command string or other action that will be used to build the specified target(s) from the specified source(s).

Once you've defined a generator, you create a Builder to use it by specifying the generator keyword argument instead of action.

def generate_actions(source, target, env, for_signature):
    return 'foobuild < %s > %s' % (source[0], target[0])
bld = Builder(generator = generate_actions,
              suffix = '.foo',
              src_suffix = '.input')
env = Environment(BUILDERS = {'Foo' : bld})
env.Foo('file')
    

% scons -Q
foobuild < file.input > file.foo

Note that it's illegal to specify both an action and a generator for a Builder.

SCons supports the ability for a Builder to modify the lists of target(s) from the specified source(s). You do this by defining an emitter function that takes as its arguments the list of the targets passed to the builder, the list of the sources passed to the builder, and the construction environment. The emitter function should return the modified lists of targets that should be built and sources from which the targets will be built.

For example, suppose you want to define a Builder that always calls a foobuild program, and you want to automatically add a new target file named new_target and a new source file named new_source whenever it's called. The SConstruct file might look like this:

def modify_targets(target, source, env):
    target.append('new_target')
    source.append('new_source')
    return target, source
bld = Builder(action = 'foobuild $TARGETS - $SOURCES',
              suffix = '.foo',
              src_suffix = '.input',
              emitter = modify_targets)
env = Environment(BUILDERS = {'Foo' : bld})
env.Foo('file')
    

And would yield the following output:

% scons -Q
foobuild file.foo new_target - file.input new_source

One very flexible thing that you can do is use a construction variable to specify different emitter functions for different construction variable. To do this, specify a string containing a construction variable expansion as the emitter when you call the Builder function, and set that construction variable to the desired emitter function in different construction environments:

bld = Builder(action = './my_command $SOURCES > $TARGET',
              suffix = '.foo',
              src_suffix = '.input',
              emitter = '$MY_EMITTER')
def modify1(target, source, env):
    return target, source + ['modify1.in']
def modify2(target, source, env):
    return target, source + ['modify2.in']
env1 = Environment(BUILDERS = {'Foo' : bld},
                   MY_EMITTER = modify1)
env2 = Environment(BUILDERS = {'Foo' : bld},
                   MY_EMITTER = modify2)
env1.Foo('file1')
env2.Foo('file2')
        

In this example, the modify1.in and modify2.in files get added to the source lists of the different commands:

% scons -Q
./my_command file1.input modify1.in > file1.foo
./my_command file2.input modify2.in > file2.foo

The site_scons directories give you a place to put Python modules and packages that you can import into your SConscript files (site_scons), add-on tools that can integrate into SCons (site_scons/site_tools), and a site_scons/site_init.py file that gets read before any SConstruct or SConscript file, allowing you to change SCons's default behavior.

Each system type (Windows, Mac, Linux, etc.) searches a canonical set of directories for site_scons; see the man page for details. The top-level SConstruct's site_scons dir is always searched last, and its dir is placed first in the tool path so it overrides all others.

If you get a tool from somewhere (the SCons wiki or a third party, for instance) and you'd like to use it in your project, a site_scons dir is the simplest place to put it. Tools come in two flavors; either a Python function that operates on an Environment or a Python module or package containing two functions, exists() and generate().

A single-function Tool can just be included in your site_scons/site_init.py file where it will be parsed and made available for use. For instance, you could have a site_scons/site_init.py file like this:

def TOOL_ADD_HEADER(env):
   """A Tool to add a header from $HEADER to the source file"""
   add_header = Builder(action=['echo "$HEADER" > $TARGET',
                                'cat $SOURCE >> $TARGET'])
   env.Append(BUILDERS = {'AddHeader' : add_header})
   env['HEADER'] = '' # set default value
      

and a SConstruct like this:

# Use TOOL_ADD_HEADER from site_scons/site_init.py
env=Environment(tools=['default', TOOL_ADD_HEADER], HEADER="=====")
env.AddHeader('tgt', 'src')
    

The TOOL_ADD_HEADER tool method will be called to add the AddHeader tool to the environment.

A more full-fledged tool with exists() and generate() methods can be installed either as a module in the file site_scons/site_tools/toolname.py or as a package in the directory site_scons/site_tools/toolname. In the case of using a package, the exists() and generate() are in the file site_scons/site_tools/toolname/__init__.py. (In all the above case toolname is replaced by the name of the tool.) Since site_scons/site_tools is automatically added to the head of the tool search path, any tool found there will be available to all environments. Furthermore, a tool found there will override a built-in tool of the same name, so if you need to change the behavior of a built-in tool, site_scons gives you the hook you need.

Many people have a library of utility Python functions they'd like to include in SConscripts; just put that module in site_scons/my_utils.py or any valid Python module name of your choice. For instance you can do something like this in site_scons/my_utils.py to add build_id and MakeWorkDir functions:

from SCons.Script import *   # for Execute and Mkdir
def build_id():
   """Return a build ID (stub version)"""
   return "100"
def MakeWorkDir(workdir):
   """Create the specified dir immediately"""
   Execute(Mkdir(workdir))
      

And then in your SConscript or any sub-SConscript anywhere in your build, you can import my_utils and use it:

import my_utils
print("build_id=" + my_utils.build_id())
my_utils.MakeWorkDir('/tmp/work')
    

Note that although you can put this library in site_scons/site_init.py, it is no better there than site_scons/my_utils.py since you still have to import that module into your SConscript. Also note that in order to refer to objects in the SCons namespace such as Environment or Mkdir or Execute in any file other than a SConstruct or SConscript you always need to do

from SCons.Script import *
    

This is true in modules in site_scons such as site_scons/site_init.py as well.

You can use any of the user- or machine-wide site dirs such as ~/.scons/site_scons instead of ./site_scons, or use the --site-dir option to point to your own dir. site_init.py and site_tools will be located under that dir. To avoid using a site_scons dir at all, even if it exists, use the --no-site-dir option.

Suppose, for example, that we want to create a simple scanner for .foo files. A .foo file contains some text that will be processed, and can include other files on lines that begin with include followed by a file name:

include filename.foo
    

Scanning a file will be handled by a Python function that you must supply. Here is a function that will use the Python re module to scan for the include lines in our example:

import re

include_re = re.compile(r'^include\s+(\S+)$', re.M)

def kfile_scan(node, env, path, arg):
    contents = node.get_text_contents()
    return env.File(include_re.findall(contents))
    

It is important to note that you have to return a list of File nodes from the scanner function, simple strings for the file names won't do. As in the examples we are showing here, you can use the File function of your current Environment in order to create nodes on the fly from a sequence of file names with relative paths.

The scanner function must accept the four specified arguments and return a list of implicit dependencies. Presumably, these would be dependencies found from examining the contents of the file, although the function can perform any manipulation at all to generate the list of dependencies.

A Scanner object is created using the Scanner function, which typically takes an skeys argument to associate the type of file suffix with this scanner. The Scanner object must then be associated with the $SCANNERS construction variable of a construction environment, typically by using the Append method:

kscan = Scanner(function = kfile_scan,
                skeys = ['.k'])
env.Append(SCANNERS = kscan)
    

When we put it all together, it looks like:

  import re

  include_re = re.compile(r'^include\s+(\S+)$', re.M)

  def kfile_scan(node, env, path):
      contents = node.get_text_contents()
      includes = include_re.findall(contents)
      return env.File(includes)

  kscan = Scanner(function = kfile_scan,
                  skeys = ['.k'])

  env = Environment(ENV = {'PATH' : '/usr/local/bin'})
  env.Append(SCANNERS = kscan)

  env.Command('foo', 'foo.k', 'kprocess < $SOURCES > $TARGET')
      

Many scanners need to search for included files or dependencies using a path variable; this is how $CPPPATH and $LIBPATH work. The path to search is passed to your scanner as the path argument. Path variables may be lists of nodes, semicolon-separated strings, or even contain SCons variables which need to be expanded. Fortunately, SCons provides the FindPathDirs function which itself returns a function to expand a given path (given as a SCons construction variable name) to a list of paths at the time the scanner is called. Deferring evaluation until that point allows, for instance, the path to contain $TARGET references which differ for each file scanned.

Using FindPathDirs is quite easy. Continuing the above example, using KPATH as the construction variable with the search path (analogous to $CPPPATH), we just modify the Scanner constructor call to include a path keyword arg:

kscan = Scanner(function = kfile_scan,
                skeys = ['.k'],
                path_function = FindPathDirs('KPATH'))
      

FindPathDirs returns a callable object that, when called, will essentially expand the elements in env['KPATH'] and tell the scanner to search in those dirs. It will also properly add related repository and variant dirs to the search list. As a side note, the returned method stores the path in an efficient way so lookups are fast even when variable substitutions may be needed. This is important since many files get scanned in a typical build.

One approach for the use of scanners is with builders. There are two optional parameters we can use with a builder source_scanner and target_scanner.

def kfile_scan(node, env, path, arg):
    contents = node.get_text_contents()
    return env.File(include_re.findall(contents))

kscan = Scanner(function = kfile_scan,
            skeys = ['.k'],
            path_function = FindPathDirs('KPATH'))

def build_function(target, source, env):
    # Code to build "target" from "source"
    return None

bld = Builder(action = build_function,
            suffix = '.foo',
            source_scanner = kscan
            src_suffix = '.input')
env = Environment(BUILDERS = {'Foo' : bld})
env.Foo('file')

      

An emitter function can modify the list of sources or targets passed to the action function when the builder is triggered.

A scanner function will not affect the list of sources or targets seen by the builder during the build action. The scanner function will however affect if the builder should be rebuilt (if any of the files sourced by the scanner have changed for example).

It's often useful to allow multiple programmers working on a project to build software from source files and/or derived files that are stored in a centrally-accessible repository, a directory copy of the source code tree. (Note that this is not the sort of repository maintained by a source code management system like BitKeeper, CVS, or Subversion.) You use the Repository method to tell SCons to search one or more central code repositories (in order) for any source files and derived files that are not present in the local build tree:

env = Environment()
env.Program('hello.c')
Repository('/usr/repository1', '/usr/repository2')
      

Multiple calls to the Repository method will simply add repositories to the global list that SCons maintains, with the exception that SCons will automatically eliminate the current directory and any non-existent directories from the list.

The above example specifies that SCons will first search for files under the /usr/repository1 tree and next under the /usr/repository2 tree. SCons expects that any files it searches for will be found in the same position relative to the top-level directory. In the above example, if the hello.c file is not found in the local build tree, SCons will search first for a /usr/repository1/hello.c file and then for a /usr/repository2/hello.c file to use in its place.

So given the SConstruct file above, if the hello.c file exists in the local build directory, SCons will rebuild the hello program as normal:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o

If, however, there is no local hello.c file, but one exists in /usr/repository1, SCons will recompile the hello program from the source file it finds in the repository:

% scons -Q
cc -o hello.o -c /usr/repository1/hello.c
cc -o hello hello.o

And similarly, if there is no local hello.c file and no /usr/repository1/hello.c, but one exists in /usr/repository2:

% scons -Q
cc -o hello.o -c /usr/repository2/hello.c
cc -o hello hello.o

We've already seen that SCons will scan the contents of a source file for #include file names and realize that targets built from that source file also depend on the #include file(s). For each directory in the $CPPPATH list, SCons will actually search the corresponding directories in any repository trees and establish the correct dependencies on any #include files that it finds in repository directory.

Unless the C compiler also knows about these directories in the repository trees, though, it will be unable to find the #include files. If, for example, the hello.c file in our previous example includes the hello.h in its current directory, and the hello.h only exists in the repository:

% scons -Q
cc -o hello.o -c hello.c
hello.c:1: hello.h: No such file or directory
    

In order to inform the C compiler about the repositories, SCons will add appropriate -I flags to the compilation commands for each directory in the $CPPPATH list. So if we add the current directory to the construction environment $CPPPATH like so:

env = Environment(CPPPATH = ['.'])
env.Program('hello.c')
Repository('/usr/repository1')
      

Then re-executing SCons yields:

% scons -Q
cc -o hello.o -c -I. -I/usr/repository1 hello.c
cc -o hello hello.o

The order of the -I options replicates, for the C preprocessor, the same repository-directory search path that SCons uses for its own dependency analysis. If there are multiple repositories and multiple $CPPPATH directories, SCons will add the repository directories to the beginning of each $CPPPATH directory, rapidly multiplying the number of -I flags. If, for example, the $CPPPATH contains three directories (and shorter repository path names!):

env = Environment(CPPPATH = ['dir1', 'dir2', 'dir3'])
env.Program('hello.c')
Repository('/r1', '/r2')
      

Then we'll end up with nine -I options on the command line, three (for each of the $CPPPATH directories) times three (for the local directory plus the two repositories):

% scons -Q
cc -o hello.o -c -Idir1 -I/r1/dir1 -I/r2/dir1 -Idir2 -I/r1/dir2 -I/r2/dir2 -Idir3 -I/r1/dir3 -I/r2/dir3 hello.c
cc -o hello hello.o

#include "hello.h"
int
main(int argc, char *argv[])
{
    printf(HELLO_MESSAGE);
    return (0);
}
      

% scons -Q
cc -o hello.o -c -I. -I/usr/repository1 /usr/repository1/hello.c
cc -o hello hello.o

SCons will also search in repositories for the SConstruct file and any specified SConscript files. This poses a problem, though: how can SCons search a repository tree for an SConstruct file if the SConstruct file itself contains the information about the pathname of the repository? To solve this problem, SCons allows you to specify repository directories on the command line using the -Y option:

% scons -Q -Y /usr/repository1 -Y /usr/repository2
    

When looking for source or derived files, SCons will first search the repositories specified on the command line, and then search the repositories specified in the SConstruct or SConscript files.

If a repository contains not only source files, but also derived files (such as object files, libraries, or executables), SCons will perform its normal MD5 signature calculation to decide if a derived file in a repository is up-to-date, or the derived file must be rebuilt in the local build directory. For the SCons signature calculation to work correctly, a repository tree must contain the .sconsign files that SCons uses to keep track of signature information.

Usually, this would be done by a build integrator who would run SCons in the repository to create all of its derived files and .sconsign files, or who would run SCons in a separate build directory and copy the resulting tree to the desired repository:

% cd /usr/repository1
% scons -Q
cc -o file1.o -c file1.c
cc -o file2.o -c file2.c
cc -o hello.o -c hello.c
cc -o hello hello.o file1.o file2.o

(Note that this is safe even if the SConstruct file lists /usr/repository1 as a repository, because SCons will remove the current build directory from its repository list for that invocation.)

Now, with the repository populated, we only need to create the one local source file we're interested in working with at the moment, and use the -Y option to tell SCons to fetch any other files it needs from the repository:

% cd $HOME/build
% edit hello.c
% scons -Q -Y /usr/repository1
cc -c -o hello.o hello.c
cc -o hello hello.o /usr/repository1/file1.o /usr/repository1/file2.o
    

Notice that SCons realizes that it does not need to rebuild local copies file1.o and file2.o files, but instead uses the already-compiled files from the repository.

If the repository tree contains the complete results of a build, and we try to build from the repository without any files in our local tree, something moderately surprising happens:

% mkdir $HOME/build2
% cd $HOME/build2
% scons -Q -Y /usr/all/repository hello
scons: `hello' is up-to-date.
    

Why does SCons say that the hello program is up-to-date when there is no hello program in the local build directory? Because the repository (not the local directory) contains the up-to-date hello program, and SCons correctly determines that nothing needs to be done to rebuild that up-to-date copy of the file.

There are, however, many times when you want to ensure that a local copy of a file always exists. A packaging or testing script, for example, may assume that certain generated files exist locally. To tell SCons to make a copy of any up-to-date repository file in the local build directory, use the Local function:

env = Environment()
hello = env.Program('hello.c')
Local(hello)
      

If we then run the same command, SCons will make a local copy of the program from the repository copy, and tell you that it is doing so:

% scons -Y /usr/all/repository hello
Local copy of hello from /usr/all/repository/hello
scons: `hello' is up-to-date.
    

(Notice that, because the act of making the local copy is not considered a "build" of the hello file, SCons still reports that it is up-to-date.)

The basic framework for multi-platform build configuration in SCons is to attach a configure context to a construction environment by calling the Configure function, perform a number of checks for libraries, functions, header files, etc., and to then call the configure context's Finish method to finish off the configuration:

env = Environment()
conf = Configure(env)
# Checks for libraries, header files, etc. go here!
env = conf.Finish()
    

SCons provides a number of basic checks, as well as a mechanism for adding your own custom checks.

Note that SCons uses its own dependency mechanism to determine when a check needs to be run--that is, SCons does not run the checks every time it is invoked, but caches the values returned by previous checks and uses the cached values unless something has changed. This saves a tremendous amount of developer time while working on cross-platform build issues.

The next sections describe the basic checks that SCons supports, as well as how to add your own custom checks.

Testing the existence of a header file requires knowing what language the header file is. A configure context has a CheckCHeader method that checks for the existence of a C header file:

env = Environment()
conf = Configure(env)
if not conf.CheckCHeader('math.h'):
    print 'Math.h must be installed!'
    Exit(1)
if conf.CheckCHeader('foo.h'):
    conf.env.Append('-DHAS_FOO_H')
env = conf.Finish()
    

Note that you can choose to terminate the build if a given header file doesn't exist, or you can modify the construction environment based on the existence of a header file.

If you need to check for the existence a C++ header file, use the CheckCXXHeader method:

env = Environment()
conf = Configure(env)
if not conf.CheckCXXHeader('vector.h'):
    print 'vector.h must be installed!'
    Exit(1)
env = conf.Finish()
    

Check for the availability of a specific function using the CheckFunc method:

env = Environment()
conf = Configure(env)
if not conf.CheckFunc('strcpy'):
    print 'Did not find strcpy(), using local version'
    conf.env.Append(CPPDEFINES = '-Dstrcpy=my_local_strcpy')
env = conf.Finish()
    

Check for the availability of a library using the CheckLib method. You only specify the basename of the library, you don't need to add a lib prefix or a .a or .lib suffix:

env = Environment()
conf = Configure(env)
if not conf.CheckLib('m'):
    print 'Did not find libm.a or m.lib, exiting!'
    Exit(1)
env = conf.Finish()
    

Because the ability to use a library successfully often depends on having access to a header file that describes the library's interface, you can check for a library and a header file at the same time by using the CheckLibWithHeader method:

env = Environment()
conf = Configure(env)
if not conf.CheckLibWithHeader('m', 'math.h', 'c'):
    print 'Did not find libm.a or m.lib, exiting!'
    Exit(1)
env = conf.Finish()
    

This is essentially shorthand for separate calls to the CheckHeader and CheckLib functions.

Check for the availability of a typedef by using the CheckType method:

env = Environment()
conf = Configure(env)
if not conf.CheckType('off_t'):
    print 'Did not find off_t typedef, assuming int'
    conf.env.Append(CCFLAGS = '-Doff_t=int')
env = conf.Finish()
    

You can also add a string that will be placed at the beginning of the test file that will be used to check for the typedef. This provide a way to specify files that must be included to find the typedef:

env = Environment()
conf = Configure(env)
if not conf.CheckType('off_t', '#include <sys/types.h>\n'):
    print 'Did not find off_t typedef, assuming int'
    conf.env.Append(CCFLAGS = '-Doff_t=int')
env = conf.Finish()
    

Check the size of a datatype by using the CheckTypeSize method:

env = Environment()
conf = Configure(env)
int_size = conf.CheckTypeSize('unsigned int')
print 'sizeof unsigned int is', int_size
env = conf.Finish()
    

% scons -Q
sizeof unsigned int is 4
scons: `.' is up to date.
    

Check for the presence of a program by using the CheckProg method:

env = Environment()
conf = Configure(env)
if not conf.CheckProg('foobar'):
  print 'Unable to find the program foobar on the system'
  Exit(1)
env = conf.Finish()
    

A custom check is a Python function that checks for a certain condition to exist on the running system, usually using methods that SCons supplies to take care of the details of checking whether a compilation succeeds, a link succeeds, a program is runnable, etc. A simple custom check for the existence of a specific library might look as follows:

mylib_test_source_file = """
#include <mylib.h>
int main(int argc, char **argv)
{
    MyLibrary mylib(argc, argv);
    return 0;
}
"""

def CheckMyLibrary(context):
    context.Message('Checking for MyLibrary...')
    result = context.TryLink(mylib_test_source_file, '.c')
    context.Result(result)
    return result
    

The Message and Result methods should typically begin and end a custom check to let the user know what's going on: the Message call prints the specified message (with no trailing newline) and the Result call prints yes if the check succeeds and no if it doesn't. The TryLink method actually tests for whether the specified program text will successfully link.

(Note that a custom check can modify its check based on any arguments you choose to pass it, or by using or modifying the configure context environment in the context.env attribute.)

This custom check function is then attached to the configure context by passing a dictionary to the Configure call that maps a name of the check to the underlying function:

env = Environment()
conf = Configure(env, custom_tests = {'CheckMyLibrary' : CheckMyLibrary})
    

You'll typically want to make the check and the function name the same, as we've done here, to avoid potential confusion.

We can then put these pieces together and actually call the CheckMyLibrary check as follows:

mylib_test_source_file = """
#include <mylib.h>
int main(int argc, char **argv)
{
    MyLibrary mylib(argc, argv);
    return 0;
}
"""

def CheckMyLibrary(context):
    context.Message('Checking for MyLibrary... ')
    result = context.TryLink(mylib_test_source_file, '.c')
    context.Result(result)
    return result

env = Environment()
conf = Configure(env, custom_tests = {'CheckMyLibrary' : CheckMyLibrary})
if not conf.CheckMyLibrary():
    print 'MyLibrary is not installed!'
    Exit(1)
env = conf.Finish()

# We would then add actual calls like Program() to build
# something using the "env" construction environment.
    

If MyLibrary is not installed on the system, the output will look like:

% scons
scons: Reading SConscript file ...
Checking for MyLibrary... no
MyLibrary is not installed!
    

If MyLibrary is installed, the output will look like:

% scons
scons: Reading SConscript file ...
Checking for MyLibrary... yes
scons: done reading SConscript
scons: Building targets ...
    .
    .
    .
    

Using multi-platform configuration as described in the previous sections will run the configuration commands even when invoking scons -c to clean targets:

% scons -Q -c
Checking for MyLibrary... yes
Removed foo.o
Removed foo
    

Although running the platform checks when removing targets doesn't hurt anything, it's usually unnecessary. You can avoid this by using the GetOption method to check whether the -c (clean) option has been invoked on the command line:

env = Environment()
if not env.GetOption('clean'):
    conf = Configure(env, custom_tests = {'CheckMyLibrary' : CheckMyLibrary})
    if not conf.CheckMyLibrary():
        print 'MyLibrary is not installed!'
        Exit(1)
    env = conf.Finish()
    

% scons -Q -c
Removed foo.o
Removed foo
    

To enable sharing of derived files, use the CacheDir function in any SConscript file:

CacheDir('/usr/local/build_cache')
       

Note that the directory you specify must already exist and be readable and writable by all developers who will be sharing derived files. It should also be in some central location that all builds will be able to access. In environments where developers are using separate systems (like individual workstations) for builds, this directory would typically be on a shared or NFS-mounted file system.

Here's what happens: When a build has a CacheDir specified, every time a file is built, it is stored in the shared cache directory along with its MD5 build signature. ^[5] On subsequent builds, before an action is invoked to build a file, SCons will check the shared cache directory to see if a file with the exact same build signature already exists. If so, the derived file will not be built locally, but will be copied into the local build directory from the shared cache directory, like so:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q -c
Removed hello.o
Removed hello
% scons -Q
Retrieved `hello.o' from cache
Retrieved `hello' from cache

Note that the CacheDir feature still calculates MD5 build sigantures for the shared cache file names even if you configure SCons to use timestamps to decide if files are up to date. (See the Chapter 6, Dependencies chapter for information about the Decider function.) Consequently, using CacheDir may reduce or eliminate any potential performance improvements from using timestamps for up-to-date decisions.

One potential drawback to using a shared cache is that the output printed by SCons can be inconsistent from invocation to invocation, because any given file may be rebuilt one time and retrieved from the shared cache the next time. This can make analyzing build output more difficult, especially for automated scripts that expect consistent output each time.

If, however, you use the --cache-show option, SCons will print the command line that it would have executed to build the file, even when it is retrieving the file from the shared cache. This makes the build output consistent every time the build is run:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q -c
Removed hello.o
Removed hello
% scons -Q --cache-show
cc -o hello.o -c hello.c
cc -o hello hello.o

The trade-off, of course, is that you no longer know whether or not SCons has retrieved a derived file from cache or has rebuilt it locally.

You may want to disable caching for certain specific files in your configuration. For example, if you only want to put executable files in a central cache, but not the intermediate object files, you can use the NoCache function to specify that the object files should not be cached:

env = Environment()
obj = env.Object('hello.c')
env.Program('hello.c')
CacheDir('cache')
NoCache('hello.o')
       

Then when you run scons after cleaning the built targets, it will recompile the object file locally (since it doesn't exist in the shared cache directory), but still realize that the shared cache directory contains an up-to-date executable program that can be retrieved instead of re-linking:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q -c
Removed hello.o
Removed hello
% scons -Q
cc -o hello.o -c hello.c
Retrieved `hello' from cache
    

Retrieving an already-built file from the shared cache is usually a significant time-savings over rebuilding the file, but how much of a savings (or even whether it saves time at all) can depend a great deal on your system or network configuration. For example, retrieving cached files from a busy server over a busy network might end up being slower than rebuilding the files locally.

In these cases, you can specify the --cache-disable command-line option to tell SCons to not retrieve already-built files from the shared cache directory:

% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q -c
Removed hello.o
Removed hello
% scons -Q
Retrieved `hello.o' from cache
Retrieved `hello' from cache
% scons -Q -c
Removed hello.o
Removed hello
% scons -Q --cache-disable
cc -o hello.o -c hello.c
cc -o hello hello.o

Sometimes, you may have one or more derived files already built in your local build tree that you wish to make available to other people doing builds. For example, you may find it more effective to perform integration builds with the cache disabled (per the previous section) and only populate the shared cache directory with the built files after the integration build has completed successfully. This way, the cache will only get filled up with derived files that are part of a complete, successful build not with files that might be later overwritten while you debug integration problems.

In this case, you can use the the --cache-force option to tell SCons to put all derived files in the cache, even if the files already exist in your local tree from having been built by a previous invocation:

% scons -Q --cache-disable
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q -c
Removed hello.o
Removed hello
% scons -Q --cache-disable
cc -o hello.o -c hello.c
cc -o hello hello.o
% scons -Q --cache-force
scons: `.' is up to date.
% scons -Q
scons: `.' is up to date.

Notice how the above sample run demonstrates that the --cache-disable option avoids putting the built hello.o and hello files in the cache, but after using the --cache-force option, the files have been put in the cache for the next invocation to retrieve.

If you allow multiple builds to update the shared cache directory simultaneously, two builds that occur at the same time can sometimes start "racing" with one another to build the same files in the same order. If, for example, you are linking multiple files into an executable program:

Program('prog',
        ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c'])
       

SCons will normally build the input object files on which the program depends in their normal, sorted order:

% scons -Q
cc -o f2.o -c f2.c
cc -o f1.o -c f1.c
cc -o f4.o -c f4.c
cc -o f5.o -c f5.c
cc -o f3.o -c f3.c
cc -o prog f1.o f2.o f3.o f4.o f5.o

But if two such builds take place simultaneously, they may each look in the cache at nearly the same time and both decide that f1.o must be rebuilt and pushed into the shared cache directory, then both decide that f2.o must be rebuilt (and pushed into the shared cache directory), then both decide that f3.o must be rebuilt... This won't cause any actual build problems--both builds will succeed, generate correct output files, and populate the cache--but it does represent wasted effort.

To alleviate such contention for the cache, you can use the --random command-line option to tell SCons to build dependencies in a random order:

  % scons -Q --random
  cc -o f3.o -c f3.c
  cc -o f1.o -c f1.c
  cc -o f5.o -c f5.c
  cc -o f2.o -c f2.c
  cc -o f4.o -c f4.c
  cc -o prog f1.o f2.o f3.o f4.o f5.o
    

Multiple builds using the --random option will usually build their dependencies in different, random orders, which minimizes the chances for a lot of contention for same-named files in the shared cache directory. Multiple simultaneous builds might still race to try to build the same target file on occasion, but long sequences of inefficient contention should be rare.

Note, of course, the --random option will cause the output that SCons prints to be inconsistent from invocation to invocation, which may be an issue when trying to compare output from different build runs.

If you want to make sure dependencies will be built in a random order without having to specify the --random on very command line, you can use the SetOption function to set the random option within any SConscript file:

SetOption('random', 1)
Program('prog',
        ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c'])
       

The basic activity when programming in Java, of course, is to take one or more .java files containing Java source code and to call the Java compiler to turn them into one or more .class files. In SCons, you do this by giving the Java Builder a target directory in which to put the .class files, and a source directory that contains the .java files:

Java('classes', 'src')
      

If the src directory contains three .java source files, then running SCons might look like this:

% scons -Q
javac -d classes -sourcepath src src/Example1.java src/Example2.java src/Example3.java

SCons will actually search the src directory tree for all of the .java files. The Java compiler will then create the necessary class files in the classes subdirectory, based on the class names found in the .java files.

In addition to searching the source directory for .java files, SCons actually runs the .java files through a stripped-down Java parser that figures out what classes are defined. In other words, SCons knows, without you having to tell it, what .class files will be produced by the javac call. So our one-liner example from the preceding section:

Java('classes', 'src')
      

Will not only tell you reliably that the .class files in the classes subdirectory are up-to-date:

% scons -Q
javac -d classes -sourcepath src src/Example1.java src/Example2.java src/Example3.java
% scons -Q classes
scons: `classes' is up to date.

But it will also remove all of the generated .class files, even for inner classes, without you having to specify them manually. For example, if our Example1.java and Example3.java files both define additional classes, and the class defined in Example2.java has an inner class, running scons -c will clean up all of those .class files as well:

% scons -Q
javac -d classes -sourcepath src src/Example1.java src/Example2.java src/Example3.java
% scons -Q -c classes
Removed classes/Example1.class
Removed classes/AdditionalClass1.class
Removed classes/Example2$Inner2.class
Removed classes/Example2.class
Removed classes/Example3.class
Removed classes/AdditionalClass3.class

To ensure correct handling of .class dependencies in all cases, you need to tell SCons which Java version is being used. This is needed because Java 1.5 changed the .class file names for nested anonymous inner classes. Use the JAVAVERSION construction variable to specify the version in use. With Java 1.6, the one-liner example can then be defined like this:

Java('classes', 'src', JAVAVERSION='1.6')
    

See JAVAVERSION in the man page for more information.

After building the class files, it's common to collect them into a Java archive (.jar) file, which you do by calling the Jar Builder method. If you want to just collect all of the class files within a subdirectory, you can just specify that subdirectory as the Jar source:

Java(target = 'classes', source = 'src')
Jar(target = 'test.jar', source = 'classes')
      

SCons will then pass that directory to the jar command, which will collect all of the underlying .class files:

% scons -Q
javac -d classes -sourcepath src src/Example1.java src/Example2.java src/Example3.java
jar cf test.jar classes

If you want to keep all of the .class files for multiple programs in one location, and only archive some of them in each .jar file, you can pass the Jar builder a list of files as its source. It's extremely simple to create multiple .jar files this way, using the lists of target class files created by calls to the Java builder as sources to the various Jar calls:

prog1_class_files = Java(target = 'classes', source = 'prog1')
prog2_class_files = Java(target = 'classes', source = 'prog2')
Jar(target = 'prog1.jar', source = prog1_class_files)
Jar(target = 'prog2.jar', source = prog2_class_files)
      

This will then create prog1.jar and prog2.jar next to the subdirectories that contain their .java files:

% scons -Q
javac -d classes -sourcepath prog1 prog1/Example1.java prog1/Example2.java
javac -d classes -sourcepath prog2 prog2/Example3.java prog2/Example4.java
jar cf prog1.jar -C classes Example1.class -C classes Example2.class
jar cf prog2.jar -C classes Example3.class -C classes Example4.class

You can generate C header and source files for implementing native methods, by using the JavaH Builder. There are several ways of using the JavaH Builder. One typical invocation might look like:

classes = Java(target = 'classes', source = 'src/pkg/sub')
JavaH(target = 'native', source = classes)
      

The source is a list of class files generated by the call to the Java Builder, and the target is the output directory in which we want the C header files placed. The target gets converted into the -d when SCons runs javah:

% scons -Q
javac -d classes -sourcepath src/pkg/sub src/pkg/sub/Example1.java src/pkg/sub/Example2.java src/pkg/sub/Example3.java
javah -d native -classpath classes pkg.sub.Example1 pkg.sub.Example2 pkg.sub.Example3

In this case, the call to javah will generate the header files native/pkg_sub_Example1.h, native/pkg_sub_Example2.h and native/pkg_sub_Example3.h. Notice that SCons remembered that the class files were generated with a target directory of classes, and that it then specified that target directory as the -classpath option to the call to javah.

Although it's more convenient to use the list of class files returned by the Java Builder as the source of a call to the JavaH Builder, you can specify the list of class files by hand, if you prefer. If you do, you need to set the $JAVACLASSDIR construction variable when calling JavaH:

Java(target = 'classes', source = 'src/pkg/sub')
class_file_list = ['classes/pkg/sub/Example1.class',
                   'classes/pkg/sub/Example2.class',
                   'classes/pkg/sub/Example3.class']
JavaH(target = 'native', source = class_file_list, JAVACLASSDIR = 'classes')
      

The $JAVACLASSDIR value then gets converted into the -classpath when SCons runs javah:

% scons -Q
javac -d classes -sourcepath src/pkg/sub src/pkg/sub/Example1.java src/pkg/sub/Example2.java src/pkg/sub/Example3.java
javah -d native -classpath classes pkg.sub.Example1 pkg.sub.Example2 pkg.sub.Example3

Lastly, if you don't want a separate header file generated for each source file, you can specify an explicit File Node as the target of the JavaH Builder:

classes = Java(target = 'classes', source = 'src/pkg/sub')
JavaH(target = File('native.h'), source = classes)
      

Because SCons assumes by default that the target of the JavaH builder is a directory, you need to use the File function to make sure that SCons doesn't create a directory named native.h. When a file is used, though, SCons correctly converts the file name into the javah -o option:

% scons -Q
javac -d classes -sourcepath src/pkg/sub src/pkg/sub/Example1.java src/pkg/sub/Example2.java src/pkg/sub/Example3.java
javah -o native.h -classpath classes pkg.sub.Example1 pkg.sub.Example2 pkg.sub.Example3

You can generate Remote Method Invocation stubs by using the RMIC Builder. The source is a list of directories, typically returned by a call to the Java Builder, and the target is an output directory where the _Stub.class and _Skel.class files will be placed:

classes = Java(target = 'classes', source = 'src/pkg/sub')
RMIC(target = 'outdir', source = classes)
      

As it did with the JavaH Builder, SCons remembers the class directory and passes it as the -classpath option to rmic:

% scons -Q
javac -d classes -sourcepath src/pkg/sub src/pkg/sub/Example1.java src/pkg/sub/Example2.java
rmic -d outdir -classpath classes pkg.sub.Example1 pkg.sub.Example2

This example would generate the files outdir/pkg/sub/Example1_Skel.class, outdir/pkg/sub/Example1_Stub.class, outdir/pkg/sub/Example2_Skel.class and outdir/pkg/sub/Example2_Stub.class.

Although the SCons code itself will run on any 2.x Python version 2.7 or later, you are perfectly free to make use of Python syntax and modules from later versions when writing your SConscript files or your own local modules. If you do this, it's usually helpful to configure SCons to exit gracefully with an error message if it's being run with a version of Python that simply won't work with your code. This is especially true if you're going to use SCons to build source code that you plan to distribute publicly, where you can't be sure of the Python version that an anonymous remote user might use to try to build your software.

SCons provides an EnsurePythonVersion function for this. You simply pass it the major and minor versions numbers of the version of Python you require:

EnsurePythonVersion(2, 5)
    

And then SCons will exit with the following error message when a user runs it with an unsupported earlier version of Python:

% scons -Q
Python 2.5 or greater required, but you have Python 2.3.6
    

You may, of course, write your SConscript files to use features that were only added in recent versions of SCons. When you publicly distribute software that is built using SCons, it's helpful to have SCons verify the version being used and exit gracefully with an error message if the user's version of SCons won't work with your SConscript files. SCons provides an EnsureSConsVersion function that verifies the version of SCons in the same the EnsurePythonVersion function verifies the version of Python, by passing in the major and minor versions numbers of the version of SCons you require:

EnsureSConsVersion(1, 0)
    

And then SCons will exit with the following error message when a user runs it with an unsupported earlier version of SCons:

% scons -Q
SCons 1.0 or greater required, but you have SCons 0.98.5
    

SCons supports an Exit function which can be used to terminate SCons while reading the SConscript files, usually because you've detected a condition under which it doesn't make sense to proceed:

if ARGUMENTS.get('FUTURE'):
    print("The FUTURE option is not supported yet!")
    Exit(2)
env = Environment()
env.Program('hello.c')
      

% scons -Q FUTURE=1
The FUTURE option is not supported yet!
% scons -Q
cc -o hello.o -c hello.c
cc -o hello hello.o

The Exit function takes as an argument the (numeric) exit status that you want SCons to exit with. If you don't specify a value, the default is to exit with 0, which indicates successful execution.

Note that the Exit function is equivalent to calling the Python sys.exit function (which the it actually calls), but because Exit is a SCons function, you don't have to import the Python sys module to use it.

The FindFile function searches for a file in a list of directories. If there is only one directory, it can be given as a simple string. The function returns a File node if a matching file exists, or None if no file is found. (See the documentation for the Glob function for an alternative way of searching for entries in a directory.)

# one directory
print("%s"%FindFile('missing', '.'))
t = FindFile('exists', '.')
print("%s %s"%(t.__class__, t))
      

% scons -Q
None
<class 'SCons.Node.FS.File'> exists
scons: `.' is up to date.

# several directories
includes = [ '.', 'include', 'src/include']
headers = [ 'nonesuch.h', 'config.h', 'private.h', 'dist.h']
for hdr in headers:
    print('%-12s: %s'%(hdr, FindFile(hdr, includes)))
      

% scons -Q
nonesuch.h  : None
config.h    : config.h
private.h   : src/include/private.h
dist.h      : include/dist.h
scons: `.' is up to date.

If the file exists in more than one directory, only the first occurrence is returned.

print(FindFile('multiple', ['sub1', 'sub2', 'sub3']))
print(FindFile('multiple', ['sub2', 'sub3', 'sub1']))
print(FindFile('multiple', ['sub3', 'sub1', 'sub2']))
      

% scons -Q
sub1/multiple
sub2/multiple
sub3/multiple
scons: `.' is up to date.

In addition to existing files, FindFile will also find derived files (that is, non-leaf files) that haven't been built yet. (Leaf files should already exist, or the build will fail!)

# Neither file exists, so build will fail
Command('derived', 'leaf', 'cat >$TARGET $SOURCE')
print(FindFile('leaf', '.'))
print(FindFile('derived', '.'))
      

% scons -Q
leaf
derived
cat > derived leaf

# Only 'leaf' exists
Command('derived', 'leaf', 'cat >$TARGET $SOURCE')
print(FindFile('leaf', '.'))
print(FindFile('derived', '.'))
      

% scons -Q
leaf
derived
cat > derived leaf

If a source file exists, FindFile will correctly return the name in the build directory.

# Only 'src/leaf' exists
VariantDir('build', 'src')
print(FindFile('leaf', 'build'))
      

% scons -Q
build/leaf
scons: `.' is up to date.

SCons supports a Flatten function which takes an input Python sequence (list or tuple) and returns a flattened list containing just the individual elements of the sequence. This can be handy when trying to examine a list composed of the lists returned by calls to various Builders. For example, you might collect object files built in different ways into one call to the Program Builder by just enclosing them in a list, as follows:

objects = [
    Object('prog1.c'),
    Object('prog2.c', CCFLAGS='-DFOO'),
]
Program(objects)
      

Because the Builder calls in SCons flatten their input lists, this works just fine to build the program:

% scons -Q
cc -o prog1.o -c prog1.c
cc -o prog2.o -c -DFOO prog2.c
cc -o prog1 prog1.o prog2.o

But if you were debugging your build and wanted to print the absolute path of each object file in the objects list, you might try the following simple approach, trying to print each Node's abspath attribute:

objects = [
    Object('prog1.c'),
    Object('prog2.c', CCFLAGS='-DFOO'),
]
Program(objects)

for object_file in objects:
    print(object_file.abspath)
      

This does not work as expected because each call to str is operating an embedded list returned by each Object call, not on the underlying Nodes within those lists:

% scons -Q
AttributeError: 'NodeList' object has no attribute 'abspath':
  File "/home/my/project/SConstruct", line 8:
    print(object_file.abspath)

The solution is to use the Flatten function so that you can pass each Node to the str separately:

objects = [
    Object('prog1.c'),
    Object('prog2.c', CCFLAGS='-DFOO'),
]
Program(objects)

for object_file in Flatten(objects):
    print(object_file.abspath)
      

% scons -Q
/home/me/project/prog1.o
/home/me/project/prog2.o
cc -o prog1.o -c prog1.c
cc -o prog2.o -c -DFOO prog2.c
cc -o prog1 prog1.o prog2.o
    

If you need to find the directory from which the user invoked the scons command, you can use the GetLaunchDir function:

env = Environment(
    LAUNCHDIR = GetLaunchDir(),
)
env.Command('directory_build_info',
            '$LAUNCHDIR/build_info'
            Copy('$TARGET', '$SOURCE'))
    

Because SCons is usually invoked from the top-level directory in which the SConstruct file lives, the Python os.getcwd() is often equivalent. However, the SCons -u, -U and -D command-line options, when invoked from a subdirectory, will cause SCons to change to the directory in which the SConstruct file is found. When those options are used, GetLaunchDir will still return the path to the user's invoking subdirectory, allowing the SConscript configuration to still get at configuration (or other) files from the originating directory.

Virtualenv is a tool to create isolated Python environments. A python application (such as SCons) may be executed within an activated virtualenv. The activation of virtualenv modifies current environment by defining some virtualenv-specific variables and modifying search PATH, such that executables installed within virtualenv's home directory are preferred over the ones installed outside of it.

Normally, SCons uses hard-coded PATH when searching for external executables, so it always picks-up executables from these pre-defined locations. This applies also to python interpreter, which is invoked by some custom SCons tools or test suites. This means, when running SCons in a virtualenv, an eventual invocation of python interpreter from SCons script will most probably jump out of virtualenv and execute python executable found in hard-coded SCons PATH, not the one which is executing SCons. Some users may consider this as an inconsistency.

This issue may be overcome by using --enable-virtualenv option. The option automatically imports virtualenv-related environment variables to all created construction environment env['ENV'], and modifies SCons PATH appropriately to prefer virtualenv's executables. Setting environment variable SCONS_ENABLE_VIRTUALENV=1 will have same effect. If virtualenv support is enabled system-vide by the environment variable, it may be suppressed with --ignore-virtualenv option.

Inside of SConscript, a global function Virtualenv is available. It returns a path to virtualenv's home directory, or None if SCons is not running from virtualenv. Note, that this function returns a path even if SCons is run from an unactivated virtualenv.

Let's look at a simple example of a misconfigured build that causes a target to be rebuilt every time SCons is run:

# Intentionally misspell the output file name in the
# command used to create the file:
Command('file.out', 'file.in', 'cp $SOURCE file.oout')
      

(Note to Windows users: The POSIX cp command copies the first file named on the command line to the second file. In our example, it copies the file.in file to the file.out file.)

Now if we run SCons multiple times on this example, we see that it re-runs the cp command every time:

% scons -Q
cp file.in file.oout
% scons -Q
cp file.in file.oout
% scons -Q
cp file.in file.oout

In this example, the underlying cause is obvious: we've intentionally misspelled the output file name in the cp command, so the command doesn't actually build the file.out file that we've told SCons to expect. But if the problem weren't obvious, it would be helpful to specify the --debug=explain option on the command line to have SCons tell us very specifically why it's decided to rebuild the target:

% scons -Q --debug=explain
scons: building `file.out' because it doesn't exist
cp file.in file.oout

If this had been a more complicated example involving a lot of build output, having SCons tell us that it's trying to rebuild the target file because it doesn't exist would be an important clue that something was wrong with the command that we invoked to build it.

Note that you can also use --warn=target-not-built which checks whether or not expected targets exist after a build rule is executed.

% scons -Q --warn=target-not-built
cp file.in file.oout

scons: warning: Cannot find target file.out after building
File "/home/bdbaddog/scons/git/as_scons/bootstrap/src/script/scons.py", line 204, in <module>

The --debug=explain option also comes in handy to help figure out what input file changed. Given a simple configuration that builds a program from three source files, changing one of the source files and rebuilding with the --debug=explain option shows very specifically why SCons rebuilds the files that it does:

% scons -Q
cc -o file1.o -c file1.c
cc -o file2.o -c file2.c
cc -o file3.o -c file3.c
cc -o prog file1.o file2.o file3.o
%     [CHANGE THE CONTENTS OF file2.c]
% scons -Q --debug=explain
scons: rebuilding `file2.o' because `file2.c' changed
cc -o file2.o -c file2.c
scons: rebuilding `prog' because `file2.o' changed
cc -o prog file1.o file2.o file3.o

This becomes even more helpful in identifying when a file is rebuilt due to a change in an implicit dependency, such as an incuded .h file. If the file1.c and file3.c files in our example both included a hello.h file, then changing that included file and re-running SCons with the --debug=explain option will pinpoint that it's the change to the included file that starts the chain of rebuilds:

% scons -Q
cc -o file1.o -c -I. file1.c
cc -o file2.o -c -I. file2.c
cc -o file3.o -c -I. file3.c
cc -o prog file1.o file2.o file3.o
%     [CHANGE THE CONTENTS OF hello.h]
% scons -Q --debug=explain
scons: rebuilding `file1.o' because `hello.h' changed
cc -o file1.o -c -I. file1.c
scons: rebuilding `file3.o' because `hello.h' changed
cc -o file3.o -c -I. file3.c
scons: rebuilding `prog' because:
           `file1.o' changed
           `file3.o' changed
cc -o prog file1.o file2.o file3.o

(Note that the --debug=explain option will only tell you why SCons decided to rebuild necessary targets. It does not tell you what files it examined when deciding not to rebuild a target file, which is often a more valuable question to answer.)

When you create a construction environment, SCons populates it with construction variables that are set up for various compilers, linkers and utilities that it finds on your system. Although this is usually helpful and what you want, it might be frustrating if SCons doesn't set certain variables that you expect to be set. In situations like this, it's sometimes helpful to use the construction environment Dump method to print all or some of the construction variables. Note that the Dump method returns the representation of the variables in the environment for you to print (or otherwise manipulate):

env = Environment()
print env.Dump()
      

On a POSIX system with gcc installed, this might generate:

% scons
scons: Reading SConscript files ...
{ 'BUILDERS': {'_InternalInstall': <function InstallBuilderWrapper at 0x700000&gt;, '_InternalInstallVersionedLib': <function InstallVersionedBuilderWrapper at 0x700000&gt;, '_InternalInstallAs': <function InstallAsBuilderWrapper at 0x700000&gt;},
  'CONFIGUREDIR': '#/.sconf_temp',
  'CONFIGURELOG': '#/config.log',
  'CPPSUFFIXES': [ '.c',
                   '.C',
                   '.cxx',
                   '.cpp',
                   '.c++',
                   '.cc',
                   '.h',
                   '.H',
                   '.hxx',
                   '.hpp',
                   '.hh',
                   '.F',
                   '.fpp',
                   '.FPP',
                   '.m',
                   '.mm',
                   '.S',
                   '.spp',
                   '.SPP',
                   '.sx'],
  'DSUFFIXES': ['.d'],
  'Dir': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'Dirs': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'ENV': { 'PATH': '/usr/local/bin:/opt/bin:/bin:/usr/bin'},
  'ESCAPE': <function escape at 0x700000&gt;,
  'File': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'HOST_ARCH': None,
  'HOST_OS': None,
  'IDLSUFFIXES': ['.idl', '.IDL'],
  'INSTALL': <function copyFunc at 0x700000&gt;,
  'INSTALLVERSIONEDLIB': <function copyFuncVersionedLib at 0x700000&gt;,
  'LIBPREFIX': 'lib',
  'LIBPREFIXES': ['$LIBPREFIX'],
  'LIBSUFFIX': '.a',
  'LIBSUFFIXES': ['$LIBSUFFIX', '$SHLIBSUFFIX'],
  'MAXLINELENGTH': 128072,
  'OBJPREFIX': '',
  'OBJSUFFIX': '.o',
  'PLATFORM': 'posix',
  'PROGPREFIX': '',
  'PROGSUFFIX': '',
  'PSPAWN': <function piped_env_spawn at 0x700000&gt;,
  'RDirs': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'SCANNERS': [<SCons.Scanner.Base object at 0x700000&gt;],
  'SHELL': 'sh',
  'SHLIBPREFIX': '$LIBPREFIX',
  'SHLIBSUFFIX': '.so',
  'SHOBJPREFIX': '$OBJPREFIX',
  'SHOBJSUFFIX': '$OBJSUFFIX',
  'SPAWN': <function subprocess_spawn at 0x700000&gt;,
  'TARGET_ARCH': None,
  'TARGET_OS': None,
  'TEMPFILE': <class 'SCons.Platform.TempFileMunge'>,
  'TEMPFILEPREFIX': '@',
  'TOOLS': ['install', 'install'],
  '_CPPDEFFLAGS': '${_defines(CPPDEFPREFIX, CPPDEFINES, CPPDEFSUFFIX, __env__)}',
  '_CPPINCFLAGS': '$( ${_concat(INCPREFIX, CPPPATH, INCSUFFIX, __env__, RDirs, TARGET, SOURCE)} $)',
  '_LIBDIRFLAGS': '$( ${_concat(LIBDIRPREFIX, LIBPATH, LIBDIRSUFFIX, __env__, RDirs, TARGET, SOURCE)} $)',
  '_LIBFLAGS': '${_concat(LIBLINKPREFIX, LIBS, LIBLINKSUFFIX, __env__)}',
  '__DRPATH': '$_DRPATH',
  '__DSHLIBVERSIONFLAGS': '${__libversionflags(__env__,"DSHLIBVERSION","_DSHLIBVERSIONFLAGS")}',
  '__LDMODULEVERSIONFLAGS': '${__libversionflags(__env__,"LDMODULEVERSION","_LDMODULEVERSIONFLAGS")}',
  '__RPATH': '$_RPATH',
  '__SHLIBVERSIONFLAGS': '${__libversionflags(__env__,"SHLIBVERSION","_SHLIBVERSIONFLAGS")}',
  '__libversionflags': <function __libversionflags at 0x700000&gt;,
  '_concat': <function _concat at 0x700000&gt;,
  '_defines': <function _defines at 0x700000&gt;,
  '_stripixes': <function _stripixes at 0x700000&gt;}
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

On a Windows system with Visual C++ the output might look like:

C:\>scons
scons: Reading SConscript files ...
{ 'BUILDERS': {'_InternalInstallVersionedLib': <function InstallVersionedBuilderWrapper at 0x700000&gt;, '_InternalInstall': <function InstallBuilderWrapper at 0x700000&gt;, 'Object': <SCons.Builder.CompositeBuilder object at 0x700000&gt;, 'PCH': <SCons.Builder.BuilderBase object at 0x700000&gt;, 'RES': <SCons.Builder.BuilderBase object at 0x700000&gt;, 'SharedObject': <SCons.Builder.CompositeBuilder object at 0x700000&gt;, 'StaticObject': <SCons.Builder.CompositeBuilder object at 0x700000&gt;, '_InternalInstallAs': <function InstallAsBuilderWrapper at 0x700000&gt;},
  'CC': 'cl',
  'CCCOM': <SCons.Action.FunctionAction object at 0x700000&gt;,
  'CCFLAGS': ['/nologo'],
  'CCPCHFLAGS': ['${(PCH and "/Yu%s \\"/Fp%s\\""%(PCHSTOP or "",File(PCH))) or ""}'],
  'CCPDBFLAGS': ['${(PDB and "/Z7") or ""}'],
  'CFILESUFFIX': '.c',
  'CFLAGS': [],
  'CONFIGUREDIR': '#/.sconf_temp',
  'CONFIGURELOG': '#/config.log',
  'CPPDEFPREFIX': '/D',
  'CPPDEFSUFFIX': '',
  'CPPSUFFIXES': [ '.c',
                   '.C',
                   '.cxx',
                   '.cpp',
                   '.c++',
                   '.cc',
                   '.h',
                   '.H',
                   '.hxx',
                   '.hpp',
                   '.hh',
                   '.F',
                   '.fpp',
                   '.FPP',
                   '.m',
                   '.mm',
                   '.S',
                   '.spp',
                   '.SPP',
                   '.sx'],
  'CXX': '$CC',
  'CXXCOM': '${TEMPFILE("$CXX $_MSVC_OUTPUT_FLAG /c $CHANGED_SOURCES $CXXFLAGS $CCFLAGS $_CCCOMCOM","$CXXCOMSTR")}',
  'CXXFILESUFFIX': '.cc',
  'CXXFLAGS': ['$(', '/TP', '$)'],
  'DSUFFIXES': ['.d'],
  'Dir': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'Dirs': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'ENV': { 'PATH': 'C:\\WINDOWS\\System32',
           'PATHEXT': '.COM;.EXE;.BAT;.CMD',
           'SystemRoot': 'C:\\WINDOWS'},
  'ESCAPE': <function escape at 0x700000&gt;,
  'File': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'HOST_ARCH': '',
  'HOST_OS': 'win32',
  'IDLSUFFIXES': ['.idl', '.IDL'],
  'INCPREFIX': '/I',
  'INCSUFFIX': '',
  'INSTALL': <function copyFunc at 0x700000&gt;,
  'INSTALLVERSIONEDLIB': <function copyFuncVersionedLib at 0x700000&gt;,
  'LIBPREFIX': '',
  'LIBPREFIXES': ['$LIBPREFIX'],
  'LIBSUFFIX': '.lib',
  'LIBSUFFIXES': ['$LIBSUFFIX'],
  'MAXLINELENGTH': 2048,
  'MSVC_SETUP_RUN': True,
  'OBJPREFIX': '',
  'OBJSUFFIX': '.obj',
  'PCHCOM': '$CXX /Fo${TARGETS[1]} $CXXFLAGS $CCFLAGS $CPPFLAGS $_CPPDEFFLAGS $_CPPINCFLAGS /c $SOURCES /Yc$PCHSTOP /Fp${TARGETS[0]} $CCPDBFLAGS $PCHPDBFLAGS',
  'PCHPDBFLAGS': ['${(PDB and "/Yd") or ""}'],
  'PLATFORM': 'win32',
  'PROGPREFIX': '',
  'PROGSUFFIX': '.exe',
  'PSPAWN': <function piped_spawn at 0x700000&gt;,
  'RC': 'rc',
  'RCCOM': <SCons.Action.FunctionAction object at 0x700000&gt;,
  'RCFLAGS': [],
  'RCSUFFIXES': ['.rc', '.rc2'],
  'RDirs': <SCons.Defaults.Variable_Method_Caller object at 0x700000&gt;,
  'SCANNERS': [<SCons.Scanner.Base object at 0x700000&gt;],
  'SHCC': '$CC',
  'SHCCCOM': <SCons.Action.FunctionAction object at 0x700000&gt;,
  'SHCCFLAGS': ['$CCFLAGS'],
  'SHCFLAGS': ['$CFLAGS'],
  'SHCXX': '$CXX',
  'SHCXXCOM': '${TEMPFILE("$SHCXX $_MSVC_OUTPUT_FLAG /c $CHANGED_SOURCES $SHCXXFLAGS $SHCCFLAGS $_CCCOMCOM","$SHCXXCOMSTR")}',
  'SHCXXFLAGS': ['$CXXFLAGS'],
  'SHELL': None,
  'SHLIBPREFIX': '',
  'SHLIBSUFFIX': '.dll',
  'SHOBJPREFIX': '$OBJPREFIX',
  'SHOBJSUFFIX': '$OBJSUFFIX',
  'SPAWN': <function spawn at 0x700000&gt;,
  'STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME': 1,
  'TARGET_ARCH': None,
  'TARGET_OS': None,
  'TEMPFILE': <class 'SCons.Platform.TempFileMunge'>,
  'TEMPFILEPREFIX': '@',
  'TOOLS': ['msvc', 'install', 'install'],
  '_CCCOMCOM': '$CPPFLAGS $_CPPDEFFLAGS $_CPPINCFLAGS $CCPCHFLAGS $CCPDBFLAGS',
  '_CPPDEFFLAGS': '${_defines(CPPDEFPREFIX, CPPDEFINES, CPPDEFSUFFIX, __env__)}',
  '_CPPINCFLAGS': '$( ${_concat(INCPREFIX, CPPPATH, INCSUFFIX, __env__, RDirs, TARGET, SOURCE)} $)',
  '_LIBDIRFLAGS': '$( ${_concat(LIBDIRPREFIX, LIBPATH, LIBDIRSUFFIX, __env__, RDirs, TARGET, SOURCE)} $)',
  '_LIBFLAGS': '${_concat(LIBLINKPREFIX, LIBS, LIBLINKSUFFIX, __env__)}',
  '_MSVC_OUTPUT_FLAG': <function msvc_output_flag at 0x700000&gt;,
  '__DSHLIBVERSIONFLAGS': '${__libversionflags(__env__,"DSHLIBVERSION","_DSHLIBVERSIONFLAGS")}',
  '__LDMODULEVERSIONFLAGS': '${__libversionflags(__env__,"LDMODULEVERSION","_LDMODULEVERSIONFLAGS")}',
  '__SHLIBVERSIONFLAGS': '${__libversionflags(__env__,"SHLIBVERSION","_SHLIBVERSIONFLAGS")}',
  '__libversionflags': <function __libversionflags at 0x700000&gt;,
  '_concat': <function _concat at 0x700000&gt;,
  '_defines': <function _defines at 0x700000&gt;,
  '_stripixes': <function _stripixes at 0x700000&gt;}
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

The construction environments in these examples have actually been restricted to just gcc and Visual C++, respectively. In a real-life situation, the construction environments will likely contain a great many more variables. Also note that we've massaged the example output above to make the memory address of all objects a constant 0x700000. In reality, you would see a different hexadecimal number for each object.

To make it easier to see just what you're interested in, the Dump method allows you to specify a specific constrcution variable that you want to disply. For example, it's not unusual to want to verify the external environment used to execute build commands, to make sure that the PATH and other environment variables are set up the way they should be. You can do this as follows:

env = Environment()
print env.Dump('ENV')
      

Which might display the following when executed on a POSIX system:

% scons
scons: Reading SConscript files ...
{ 'PATH': '/usr/local/bin:/opt/bin:/bin:/usr/bin'}
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

And the following when executed on a Windows system:

C:\>scons
scons: Reading SConscript files ...
{ 'PATH': 'C:\\WINDOWS\\System32:/usr/bin',
  'PATHEXT': '.COM;.EXE;.BAT;.CMD',
  'SystemRoot': 'C:\\WINDOWS'}
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.

Sometimes the best way to try to figure out what SCons is doing is simply to take a look at the dependency graph that it constructs based on your SConscript files. The --tree option will display all or part of the SCons dependency graph in an "ASCII art" graphical format that shows the dependency hierarchy.

For example, given the following input SConstruct file:

env = Environment(CPPPATH = ['.'])
env.Program('prog', ['f1.c', 'f2.c', 'f3.c'])
      

Running SCons with the --tree=all option yields:

% scons -Q --tree=all
cc -o f1.o -c -I. f1.c
cc -o f2.o -c -I. f2.c
cc -o f3.o -c -I. f3.c
cc -o prog f1.o f2.o f3.o
+-.
  +-SConstruct
  +-f1.c
  +-f1.o
  | +-f1.c
  | +-inc.h
  +-f2.c
  +-f2.o
  | +-f2.c
  | +-inc.h
  +-f3.c
  +-f3.o
  | +-f3.c
  | +-inc.h
  +-inc.h
  +-prog
    +-f1.o
    | +-f1.c
    | +-inc.h
    +-f2.o
    | +-f2.c
    | +-inc.h
    +-f3.o
      +-f3.c
      +-inc.h

The tree will also be printed when the -n (no execute) option is used, which allows you to examine the dependency graph for a configuration without actually rebuilding anything in the tree.

The --tree option only prints the dependency graph for the specified targets (or the default target(s) if none are specified on the command line). So if you specify a target like f2.o on the command line, the --tree option will only print the dependency graph for that file:

% scons -Q --tree=all f2.o
cc -o f2.o -c -I. f2.c
+-f2.o
  +-f2.c
  +-inc.h

This is, of course, useful for restricting the output from a very large build configuration to just a portion in which you're interested. Multiple targets are fine, in which case a tree will be printed for each specified target:

% scons -Q --tree=all f1.o f3.o
cc -o f1.o -c -I. f1.c
+-f1.o
  +-f1.c
  +-inc.h
cc -o f3.o -c -I. f3.c
+-f3.o
  +-f3.c
  +-inc.h

The status argument may be used to tell SCons to print status information about each file in the dependency graph:

% scons -Q --tree=status
cc -o f1.o -c -I. f1.c
cc -o f2.o -c -I. f2.c
cc -o f3.o -c -I. f3.c
cc -o prog f1.o f2.o f3.o
 E         = exists
  R        = exists in repository only
   b       = implicit builder
   B       = explicit builder
    S      = side effect
     P     = precious
      A    = always build
       C   = current
        N  = no clean
         H = no cache

[E b      ]+-.
[E     C  ]  +-SConstruct
[E     C  ]  +-f1.c
[E B   C  ]  +-f1.o
[E     C  ]  | +-f1.c
[E     C  ]  | +-inc.h
[E     C  ]  +-f2.c
[E B   C  ]  +-f2.o
[E     C  ]  | +-f2.c
[E     C  ]  | +-inc.h
[E     C  ]  +-f3.c
[E B   C  ]  +-f3.o
[E     C  ]  | +-f3.c
[E     C  ]  | +-inc.h
[E     C  ]  +-inc.h
[E B   C  ]  +-prog
[E B   C  ]    +-f1.o
[E     C  ]    | +-f1.c
[E     C  ]    | +-inc.h
[E B   C  ]    +-f2.o
[E     C  ]    | +-f2.c
[E     C  ]    | +-inc.h
[E B   C  ]    +-f3.o
[E     C  ]      +-f3.c
[E     C  ]      +-inc.h

Note that --tree=all,status is equivalent; the all is assumed if only status is present. As an alternative to all, you can specify --tree=derived to have SCons only print derived targets in the tree output, skipping source files (like .c and .h files):

% scons -Q --tree=derived
cc -o f1.o -c -I. f1.c
cc -o f2.o -c -I. f2.c
cc -o f3.o -c -I. f3.c
cc -o prog f1.o f2.o f3.o
+-.
  +-f1.o
  +-f2.o
  +-f3.o
  +-prog
    +-f1.o
    +-f2.o
    +-f3.o

You can use the status modifier with derived as well:

% scons -Q --tree=derived,status
cc -o f1.o -c -I. f1.c
cc -o f2.o -c -I. f2.c
cc -o f3.o -c -I. f3.c
cc -o prog f1.o f2.o f3.o
 E         = exists
  R        = exists in repository only
   b       = implicit builder
   B       = explicit builder
    S      = side effect
     P     = precious
      A    = always build
       C   = current
        N  = no clean
         H = no cache

[E b      ]+-.
[E B   C  ]  +-f1.o
[E B   C  ]  +-f2.o
[E B   C  ]  +-f3.o
[E B   C  ]  +-prog
[E B   C  ]    +-f1.o
[E B   C  ]    +-f2.o
[E B   C  ]    +-f3.o

Note that the order of the --tree= arguments doesn't matter; --tree=status,derived is completely equivalent.

The default behavior of the --tree option is to repeat all of the dependencies each time the library dependency (or any other dependency file) is encountered in the tree. If certain target files share other target files, such as two programs that use the same library:

env = Environment(CPPPATH = ['.'],
                  LIBS = ['foo'],
                  LIBPATH = ['.'])
env.Library('foo', ['f1.c', 'f2.c', 'f3.c'])
env.Program('prog1.c')
env.Program('prog2.c')
      

Then there can be a lot of repetition in the --tree= output:

% scons -Q --tree=all
cc -o f1.o -c -I. f1.c
cc -o f2.o -c -I. f2.c
cc -o f3.o -c -I. f3.c
ar rc libfoo.a f1.o f2.o f3.o
ranlib libfoo.a
cc -o prog1.o -c -I. prog1.c
cc -o prog1 prog1.o -L. -lfoo
cc -o prog2.o -c -I. prog2.c
cc -o prog2 prog2.o -L. -lfoo
+-.
  +-SConstruct
  +-f1.c
  +-f1.o
  | +-f1.c
  | +-inc.h
  +-f2.c
  +-f2.o
  | +-f2.c
  | +-inc.h
  +-f3.c
  +-f3.o
  | +-f3.c
  | +-inc.h
  +-inc.h
  +-libfoo.a
  | +-f1.o
  | | +-f1.c
  | | +-inc.h
  | +-f2.o
  | | +-f2.c
  | | +-inc.h
  | +-f3.o
  |   +-f3.c
  |   +-inc.h
  +-prog1
  | +-prog1.o
  | | +-prog1.c
  | | +-inc.h
  | +-libfoo.a
  |   +-f1.o
  |   | +-f1.c
  |   | +-inc.h
  |   +-f2.o
  |   | +-f2.c
  |   | +-inc.h
  |   +-f3.o
  |     +-f3.c
  |     +-inc.h
  +-prog1.c
  +-prog1.o
  | +-prog1.c
  | +-inc.h
  +-prog2
  | +-prog2.o
  | | +-prog2.c
  | | +-inc.h
  | +-libfoo.a
  |   +-f1.o
  |   | +-f1.c
  |   | +-inc.h
  |   +-f2.o
  |   | +-f2.c
  |   | +-inc.h
  |   +-f3.o
  |     +-f3.c
  |     +-inc.h
  +-prog2.c
  +-prog2.o
    +-prog2.c
    +-inc.h

In a large configuration with many internal libraries and include files, this can very quickly lead to huge output trees. To help make this more manageable, a prune modifier may be added to the option list, in which case SCons will print the name of a target that has already been visited during the tree-printing in [square brackets] as an indication that the dependencies of the target file may be found by looking farther up the tree:

% scons -Q --tree=prune
cc -o f1.o -c -I. f1.c
cc -o f2.o -c -I. f2.c
cc -o f3.o -c -I. f3.c
ar rc libfoo.a f1.o f2.o f3.o
ranlib libfoo.a
cc -o prog1.o -c -I. prog1.c
cc -o prog1 prog1.o -L. -lfoo
cc -o prog2.o -c -I. prog2.c
cc -o prog2 prog2.o -L. -lfoo
+-.
  +-SConstruct
  +-f1.c
  +-f1.o
  | +-f1.c
  | +-inc.h
  +-f2.c
  +-f2.o
  | +-f2.c
  | +-inc.h
  +-f3.c
  +-f3.o
  | +-f3.c
  | +-inc.h
  +-inc.h
  +-libfoo.a
  | +-[f1.o]
  | +-[f2.o]
  | +-[f3.o]
  +-prog1
  | +-prog1.o
  | | +-prog1.c
  | | +-inc.h
  | +-[libfoo.a]
  +-prog1.c
  +-[prog1.o]
  +-prog2
  | +-prog2.o
  | | +-prog2.c
  | | +-inc.h
  | +-[libfoo.a]
  +-prog2.c
  +-[prog2.o]

Like the status keyword, the prune argument by itself is equivalent to --tree=all,prune.

Sometimes it's useful to look at the pre-substitution string that SCons uses to generate the command lines it executes. This can be done with the --debug=presub option:

% scons -Q --debug=presub
Building prog.o with action:
  $CC -o $TARGET -c $CFLAGS $CCFLAGS $_CCOMCOM $SOURCES
cc -o prog.o -c -I. prog.c
Building prog with action:
  $SMART_LINKCOM
cc -o prog prog.o
    

To get some insight into what library names SCons is searching for, and in which directories it is searching, Use the --debug=findlibs option. Given the following input SConstruct file:

env = Environment(LIBPATH = ['libs1', 'libs2'])
env.Program('prog.c', LIBS=['foo', 'bar'])
      

And the libraries libfoo.a and libbar.a in libs1 and libs2, respectively, use of the --debug=findlibs option yields:

% scons -Q --debug=findlibs
  findlibs: looking for 'libfoo.a' in 'libs1' ...
  findlibs: ... FOUND 'libfoo.a' in 'libs1'
  findlibs: looking for 'libfoo.so' in 'libs1' ...
  findlibs: looking for 'libfoo.so' in 'libs2' ...
  findlibs: looking for 'libbar.a' in 'libs1' ...
  findlibs: looking for 'libbar.a' in 'libs2' ...
  findlibs: ... FOUND 'libbar.a' in 'libs2'
  findlibs: looking for 'libbar.so' in 'libs1' ...
  findlibs: looking for 'libbar.so' in 'libs2' ...
cc -o prog.o -c prog.c
cc -o prog prog.o -Llibs1 -Llibs2 -lfoo -lbar

In general, SCons tries to keep its error messages short and informative. That means we usually try to avoid showing the stack traces that are familiar to experienced Python programmers, since they usually contain much more information than is useful to most people.

For example, the following SConstruct file:

Program('prog.c')
      

Generates the following error if the prog.c file does not exist:

% scons -Q
scons: *** [prog.o] Source `prog.c' not found, needed by target `prog.o'.

In this case, the error is pretty obvious. But if it weren't, and you wanted to try to get more information about the error, the --debug=stacktrace option would show you exactly where in the SCons source code the problem occurs:

% scons -Q --debug=stacktrace
scons: *** [prog.o] Source `prog.c' not found, needed by target `prog.o'.
scons: internal stack trace:
  File "bootstrap/src/engine/SCons/Job.py", line 199, in start
    task.prepare()
  File "bootstrap/src/engine/SCons/Script/Main.py", line 177, in prepare
    return SCons.Taskmaster.OutOfDateTask.prepare(self)
  File "bootstrap/src/engine/SCons/Taskmaster.py", line 198, in prepare
    executor.prepare()
  File "bootstrap/src/engine/SCons/Executor.py", line 430, in prepare
    raise SCons.Errors.StopError(msg % (s, self.batches[0].targets[0]))

Of course, if you do need to dive into the SCons source code, we'd like to know if, or how, the error messages or troubleshooting options could have been improved to avoid that. Not everyone has the necessary time or Python skill to dive into the source code, and we'd like to improve SCons for those people as well...

The internal SCons subsystem that handles walking the dependency graph and controls the decision-making about what to rebuild is the Taskmaster. SCons supports a --taskmastertrace option that tells the Taskmaster to print information about the children (dependencies) of the various Nodes on its walk down the graph, which specific dependent Nodes are being evaluated, and in what order.

The --taskmastertrace option takes as an argument the name of a file in which to put the trace output, with - (a single hyphen) indicating that the trace messages should be printed to the standard output:

env = Environment(CPPPATH = ['.'])
env.Program('prog.c')
      

% scons -Q --taskmastertrace=- prog

Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <no_state   0   'prog'> and its children:
Taskmaster:        <no_state   0   'prog.o'>
Taskmaster:      adjusted ref count: <pending    1   'prog'>, child 'prog.o'
Taskmaster:     Considering node <no_state   0   'prog.o'> and its children:
Taskmaster:        <no_state   0   'prog.c'>
Taskmaster:        <no_state   0   'inc.h'>
Taskmaster:      adjusted ref count: <pending    1   'prog.o'>, child 'prog.c'
Taskmaster:      adjusted ref count: <pending    2   'prog.o'>, child 'inc.h'
Taskmaster:     Considering node <no_state   0   'prog.c'> and its children:
Taskmaster: Evaluating <pending    0   'prog.c'>

Task.make_ready_current(): node <pending    0   'prog.c'>
Task.prepare():      node <up_to_date 0   'prog.c'>
Task.executed_with_callbacks(): node <up_to_date 0   'prog.c'>
Task.postprocess():  node <up_to_date 0   'prog.c'>
Task.postprocess():  removing <up_to_date 0   'prog.c'>
Task.postprocess():  adjusted parent ref count <pending    1   'prog.o'>

Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <no_state   0   'inc.h'> and its children:
Taskmaster: Evaluating <pending    0   'inc.h'>

Task.make_ready_current(): node <pending    0   'inc.h'>
Task.prepare():      node <up_to_date 0   'inc.h'>
Task.executed_with_callbacks(): node <up_to_date 0   'inc.h'>
Task.postprocess():  node <up_to_date 0   'inc.h'>
Task.postprocess():  removing <up_to_date 0   'inc.h'>
Task.postprocess():  adjusted parent ref count <pending    0   'prog.o'>

Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <pending    0   'prog.o'> and its children:
Taskmaster:        <up_to_date 0   'prog.c'>
Taskmaster:        <up_to_date 0   'inc.h'>
Taskmaster: Evaluating <pending    0   'prog.o'>

Task.make_ready_current(): node <pending    0   'prog.o'>
Task.prepare():      node <executing  0   'prog.o'>
Task.execute():      node <executing  0   'prog.o'>
cc -o prog.o -c -I. prog.c
Task.executed_with_callbacks(): node <executing  0   'prog.o'>
Task.postprocess():  node <executed   0   'prog.o'>
Task.postprocess():  removing <executed   0   'prog.o'>
Task.postprocess():  adjusted parent ref count <pending    0   'prog'>

Taskmaster: Looking for a node to evaluate
Taskmaster:     Considering node <pending    0   'prog'> and its children:
Taskmaster:        <executed   0   'prog.o'>
Taskmaster: Evaluating <pending    0   'prog'>

Task.make_ready_current(): node <pending    0   'prog'>
Task.prepare():      node <executing  0   'prog'>
Task.execute():      node <executing  0   'prog'>
cc -o prog prog.o
Task.executed_with_callbacks(): node <executing  0   'prog'>
Task.postprocess():  node <executed   0   'prog'>

Taskmaster: Looking for a node to evaluate
Taskmaster: No candidate anymore.

The --taskmastertrace option doesn't provide information about the actual calculations involved in deciding if a file is up-to-date, but it does show all of the dependencies it knows about for each Node, and the order in which those dependencies are evaluated. This can be useful as an alternate way to determine whether or not your SCons configuration, or the implicit dependency scan, has actually identified all the correct dependencies you want it to.

Sometimes SCons doesn't build the target you want and it's difficult to figure out why. You can use the --debug=prepare option to see all the targets SCons is considering, whether they are already up-to-date or not. The message is printed before SCons decides whether to build the target.

When using the Duplicate option to create variant dirs, sometimes you may find files not getting copied to where you expect (or not at all), or files mysteriously disappearing. These are usually because of a misconfiguration of some kind in the SConstruct/SConscript, but they can be tricky to debug. The --debug=duplicate option shows each time a variant file is unlinked and relinked from its source (or copied, depending on settings), and also shows a message for removing "stale" variant-dir files that no longer have a corresponding source file. It also prints a line for each target that's removed just before building, since that can also be mistaken for the same thing.