1.1. Installing Python

Because SCons is written in Python, you must obviously 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.

       $ python -V
       Python 2.5.1
    

And on a Windows system with Python installed:

       C:\>python -V
       Python 2.5.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.

(Note that the -V option was added to Python version 2.0, so if your system only has an earlier version available you may see an "Unknown option: -V" error message.)

The standard location for information about downloading and installing Python is http://www.python.org/download/. See that page for information about how to download and install Python on your system.

SCons will work with any version of Python from 1.5.2 or later. If you need to install Python and have a choice, we recommend using the most recent Python 2.5 version available. Python 2.5 has significant improvements the help speed up the performance of SCons'.

1.2. Installing SCons From Pre-Built Packages

SCons comes pre-packaged for installation on a number of systems, including Linux and Windows systems. You do not need to read this entire section, you should only need to read the section appropriate to the type of system you're running on.

        # rpm -Uvh scons-0.96-1.noarch.rpm
      

        # apt-get install scons
      

1.3. Building and Installing SCons on Any System

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

The first step is to download either the scons-1.0.0.tar.gz or scons-1.0.0.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-1.0.0, usually in your local directory. Then change your working directory to that directory and install SCons by executing the following commands:

      # cd scons-1.0.0
      # python setup.py install
    

This will build SCons, install the scons script in the default system scripts directory (/usr/local/bin or C:\Python25\Scripts), and will install the SCons build engine in an appropriate stand-alone library directory (/usr/local/lib/scons or C:\Python25\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
      

2.1. Building Simple C / C++ Programs

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 /nologo /c hello.c /Fohello.obj
      link /nologo /OUT:hello.exe hello.obj
      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.)

2.2. Building Object Files

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 /nologo /c hello.c /Fohello.obj
      scons: done building targets.
   

2.3. Simple Java Builds

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

2.4. Cleaning Up After a Build

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 /nologo /c hello.c /Fohello.obj
      link /nologo /OUT:hello.exe hello.obj
      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.

2.5. The SConstruct File

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.
     

2.6. Making the SCons Output Less Verbose

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 /nologo /c hello.c /Fohello.obj
      link /nologo /OUT:hello.exe hello.obj
      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 /nologo /c hello.c /Fohello.obj
      link /nologo /OUT:hello.exe hello.obj
   

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.

3.1. Specifying the Name of the Target (Output) File

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 /nologo /c hello.c /Fohello.obj
       link /nologo /OUT:new_hello.exe hello.obj
    

3.2. Compiling Multiple Source Files

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 /nologo /c file1.c /Fofile1.obj
       cl /nologo /c file2.c /Fofile2.obj
       cl /nologo /c prog.c /Foprog.obj
       link /nologo /OUT:program.exe prog.obj file1.obj file2.obj
    

3.3. Making a list of files with Glob

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 and Repositories, and returning strings rather than Nodes.

3.4. Specifying Single Files Vs. Lists of Files

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.

Although SCons functions are forgiving about whether or not you use a string vs. a list for a single file name, Python itself is more strict about treating lists and strings differently. So where SCons allows either a string or list: # The following two calls both work correctly: Program('program1', 'program1.c') Program('program2', ['program2.c']) Trying to do "Python things" that mix strings and lists will cause errors or lead to incorrect results: 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'])

3.5. Making Lists of Files Easier to Read

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 string.split() method, 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.)

3.6. Keyword Arguments

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.

3.7. Compiling Multiple Programs

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.

3.8. Sharing Source Files Between Multiple Programs

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, 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 only need to be built 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.

4.1. Building Libraries

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 /nologo /c f1.c /Fof1.obj
      cl /nologo /c f2.c /Fof2.obj
      cl /nologo /c f3.c /Fof3.obj
      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 /nologo /c f1.c /Fof1.obj
        cl /nologo /c f2.c /Fof2.obj
        cl /nologo /c f3.c /Fof3.obj
        link /nologo /dll /out:foo.dll /implib:foo.lib f1.obj f2.obj f3.obj
        RegServerFunc(target, source, env)
      

4.2. Linking with Libraries

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 /nologo /c f1.c /Fof1.obj
      cl /nologo /c f2.c /Fof2.obj
      cl /nologo /c f3.c /Fof3.obj
      lib /nologo /OUT:foo.lib f1.obj f2.obj f3.obj
      cl /nologo /c prog.c /Foprog.obj
      link /nologo /OUT:prog.exe /LIBPATH:. foo.lib bar.lib prog.obj
    

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.

4.3. Finding Libraries: the $LIBPATH Construction Variable

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 /nologo /c prog.c /Foprog.obj
      link /nologo /OUT:prog.exe /LIBPATH:\usr\lib /LIBPATH:\usr\local\lib m.lib prog.obj
    

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

5.1. Builder Methods Return Lists of Target Nodes

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 source files 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 listing 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 -DGOODBYE /c goodbye.c /Fogoodbye.obj
       cl -DHELLO /c hello.c /Fohello.obj
       link /nologo /OUT:hello.exe hello.obj goodbye.obj
    

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

5.2. Explicitly Creating File and Directory Nodes

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

5.3. Printing Node File Names

One of the most common things you can do with a Node is use it to print the file name that the node represents. For example, the following SConstruct file:

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

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

      object_list = Object('hello.c')
      program_list = Program(object_list)
      print "The object file is:", object_list[0]
      print "The program file is:", 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 /nologo /c hello.c /Fohello.obj
      link /nologo /OUT:hello.exe hello.obj
    

5.4. Using a Node's File Name as a String

Printing a Node's name as described in the previous section works because the string representation of a Node 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 program_name, "does not exist!"
    

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
    

6.1. Deciding When an Input File Has Changed: the Decider Function

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
         % 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')
        Decider('MD5')
      

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

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

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

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

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

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

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

        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
      

6.2. Older Functions for Deciding When an Input File Has Changed

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. Although they're not officially deprecated yet, 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 existing 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')
      

6.3. Implicit Dependencies: The $CPPPATH Construction Variable

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.
       % edit hello.h
           [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 /nologo /Iinclude /I\home\project\inc /c hello.c /Fohello.obj
       link /nologo /OUT:hello.exe hello.obj
    

6.4. Caching Implicit Dependencies

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:

• When --implicit-cache is used, SCons will ignore any changes that may have been made to search paths (like $CPPPATH or $LIBPATH,). This can lead to SCons not rebuilding a file if a change to $CPPPATH would normally cause a different, same-named file from a different directory to be used.

• When --implicit-cache is used, SCons will not detect if a same-named file has been added to a directory that is earlier in the search path than the directory in which the file was found last time.

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

6.5. Explicit Dependencies: the Depends Function

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
    

6.6. Ignoring Dependencies: the Ignore Function

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 = Program('hello.c')
      Ignore(hello, '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')
    

6.7. Order-Only Dependencies: the Requires Function

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 version.o 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
      gcc -o hello.o -c hello.c
      gcc -o version.o -c version.c
      gcc -o hello hello.o version.o
      % scons -Q
      gcc -o version.o -c version.c
      gcc -o hello hello.o version.o
      % scons -Q
      gcc -o version.o -c version.c
      gcc -o hello hello.o version.o
    

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 re-building the version.o file, and therefore re-linking the hello executable, only when the hello.c has changed:

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

6.8. The AlwaysBuild Function

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.
    

7.1. Using Values From the External Environment

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 statuement 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, for information on how to do this.

7.2. Construction Environments

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()
       

     import os

         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:", 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()
         dict = env.Dictionary()
         keys = dict.keys()
         keys.sort()
         for key in keys:
             print "construction variable = '%s', value = '%s'" % (key, dict[key])
      

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

        env = Environment(CCFLAGS = '-DFOO')
        print "CCCOM is:", 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:", env.subst('$CCCOM')
      

        % scons -Q
        CCCOM is: gcc -DFOO -c -o
        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 =", env['NEW_VARIABLE']
      

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

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

         env.Replace(CCFLAGS = '-DDEFINE2')
         print "CCFLAGS =", 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 =", 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 =", env['NEW_VARIABLE']
      

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

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

7.3. Controlling the Execution Environment for Issued Commands

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 likley 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')
      

11.1. Providing Build Help: the Help Function

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

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

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.

11.2. Controlling How SCons Prints Build Commands: the $*COMSTR Variables

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

11.3. Providing Build Progress Output: the Progress Function

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

11.4. Printing Detailed Build Status: the GetBuildFailures Function

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: *** Source `source' not found, needed by target `target'.  Stop.
          FAILED!!!!
          Failed building Source `source' not found, needed by target `target'.
    

12.1. Command-Line Options

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"
      

        import os
        num_cpu = int(os.environ.get('NUM_CPU', 2))
        SetOption('num_jobs', num_cpu)
        print "running with -j", 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"
      

12.2. Command-Line variable=value Build Variables

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 followig 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()
           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('custom.py')
           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')
             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
          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
          File "/home/my/project/SConstruct", line 5, in <module>
          % scons -Q COLOR=BLUE foo.o
          
          scons: *** Invalid value for option COLOR: BLUE
          File "/home/my/project/SConstruct", line 5, in <module>
          % scons -Q COLOR=nAvY foo.o
          
          scons: *** Invalid value for option COLOR: nAvY
          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:", unknown.keys()
               Exit(1)
           env.Program('foo.c')
      

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

12.3. Command-Line Targets

        if 'bar' in COMMAND_LINE_TARGETS:
            print "Don't forget to copy `bar' to the archive!"
        Default(Program('foo.c'))
        Program('bar.c')
      

        % scons -Q
        cc -o foo.o -c foo.c
        cc -o foo foo.o
        % scons -Q bar
        Don't forget to copy `bar' to the archive!
        cc -o bar.o -c bar.c
        cc -o bar bar.o
      

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

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

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

         env = Environment()
         prog1 = env.Program('prog1.c')
         Default(prog1)
         prog2 = env.Program('prog2.c')
         prog3 = env.Program('prog3.c')
         Default(prog3)
      

         env = Environment()
         prog1 = env.Program('prog1.c')
         prog2 = env.Program('prog2.c')
         prog3 = env.Program('prog3.c')
         Default(prog1, prog3)
      

         % scons -Q
         cc -o prog1.o -c prog1.c
         cc -o prog1 prog1.o
         cc -o prog3.o -c prog3.c
         cc -o prog3 prog3.o
         % scons -Q .
         cc -o prog2.o -c prog2.c
         cc -o prog2 prog2.o
      

         env = Environment()
         env.Program(['prog1/main.c', 'prog1/foo.c'])
         env.Program(['prog2/main.c', 'prog2/bar.c'])
         Default('prog1')
      

         % scons -Q
         cc -o prog1/foo.o -c prog1/foo.c
         cc -o prog1/main.o -c prog1/main.c
         cc -o prog1/main prog1/main.o prog1/foo.o
         % scons -Q
         scons: `prog1' is up to date.
         % scons -Q .
         cc -o prog2/bar.o -c prog2/bar.c
         cc -o prog2/main.o -c prog2/main.c
         cc -o prog2/main prog2/main.o prog2/bar.o
      

         env = Environment()
         prog1 = env.Program('prog1.c')
         prog2 = env.Program('prog2.c')
         Default(None)
      

         % scons -Q
         scons: *** No targets specified and no Default() targets found.  Stop.
         % scons -Q .
         cc -o prog1.o -c prog1.c
         cc -o prog1 prog1.o
         cc -o prog2.o -c prog2.c
         cc -o prog2 prog2.o
      

           prog1 = Program('prog1.c')
           Default(prog1)
           print "DEFAULT_TARGETS is", map(str, DEFAULT_TARGETS)
        

           % scons
           scons: Reading SConscript files ...
           DEFAULT_TARGETS is ['prog1']
           scons: done reading SConscript files.
           scons: Building targets ...
           cc -o prog1.o -c prog1.c
           cc -o prog1 prog1.o
           scons: done building targets.
        

           prog1 = Program('prog1.c')
           Default(prog1)
           print "DEFAULT_TARGETS is now", map(str, DEFAULT_TARGETS)
           prog2 = Program('prog2.c')
           Default(prog2)
           print "DEFAULT_TARGETS is now", map(str, DEFAULT_TARGETS)
        

           % scons
           scons: Reading SConscript files ...
           DEFAULT_TARGETS is now ['prog1']
           DEFAULT_TARGETS is now ['prog1', 'prog2']
           scons: done reading SConscript files.
           scons: Building targets ...
           cc -o prog1.o -c prog1.c
           cc -o prog1 prog1.o
           cc -o prog2.o -c prog2.c
           cc -o prog2 prog2.o
           scons: done building targets.
        

        if COMMAND_LINE_TARGETS:
            targets = COMMAND_LINE_TARGETS
        else:
            targets = DEFAULT_TARGETS
      

        prog1 = Program('prog1.c')
        Program('prog2.c')
        Default(prog1)
        print "BUILD_TARGETS is", map(str, BUILD_TARGETS)
      

        % scons -Q
        BUILD_TARGETS is ['prog1']
        cc -o prog1.o -c prog1.c
        cc -o prog1 prog1.o
        % scons -Q prog2
        BUILD_TARGETS is ['prog2']
        cc -o prog2.o -c prog2.c
        cc -o prog2 prog2.o
        % scons -Q -c .
        BUILD_TARGETS is ['.']
        Removed prog1.o
        Removed prog1
        Removed prog2.o
        Removed prog2
      

13.1. Installing Multiple Files in a Directory

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"
    

13.2. Installing a File Under a Different Name

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"
    

13.3. Installing Multiple Files Under Different Names

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"
    

14.1. Copying Files or Directories: The Copy Factory

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")
    

14.2. Deleting Files or Directories: The Delete Factory

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"),
              ])
    

When 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!

14.3. Moving (Renaming) Files or Directories: The Move Factory

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")
    

14.4. Updating the Modification Time of a File: The Touch Factory

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")
    

14.5. Creating a Directory: The Mkdir Factory

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] No such file or directory
    

14.6. Changing File or Directory Permissions: The Chmod Factory

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)
    

14.7. Executing an action immediately: the Execute Function

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 wrapping it up in 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.

15.1. Preventing target removal during build: the Precious Function

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.

15.2. Preventing target removal during clean: the NoClean Function

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.
    

15.3. Removing additional files during clean: the Clean Function

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
    

16.1. SConscript Files

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.

16.2. Path Names Are Relative to the SConscript Directory

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.

16.3. Top-Level Path Names in Subsidiary SConscript Files

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 17, below, for information about how to build the object file in a different subdirectory.)

16.4. Absolute Path Names

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 17, below, for information about how to build the object file in a different subdirectory.)

16.5. Sharing Environments (and Other Variables) Between SConscript Files

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
      

17.1. Specifying a Variant Directory Tree as Part of an SConscript Call

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.

17.2. Why SCons Duplicates Source Files in a Variant Directory Tree

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

17.3. Telling SCons to Not Duplicate Source Files in the Variant Directory Tree

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
    

17.4. The VariantDir Function

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
    

17.5. Using VariantDir With an SConscript File

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.

17.6. Using Glob with VariantDir

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.

19.1. Writing Builders That Execute External Commands

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.

19.2. Attaching a Builder to a Construction Environment

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 so attached to our construction environment 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 instance 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
    

19.3. Letting SCons Handle The File Suffixes

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.

19.4. Builders That Execute Python Functions

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"])
    

19.5. Builders That Create Actions Using a Generator

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.

19.6. Builders That Modify the Target or Source Lists Using an Emitter

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 is specify 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')
        import os
        env1['ENV']['PATH'] = env2['ENV']['PATH'] + os.pathsep + os.getcwd()
        env2['ENV']['PATH'] = env2['ENV']['PATH'] + os.pathsep + os.getcwd()
      

    

      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
    

19.7. Where To Put Your Custom Builders and Tools

The site_scons directory gives you a place to put Python modules you can import into your SConscripts (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, allowing you to change SCons's default behavior.

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, the 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 file 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.

Similarly, a more full-fledged tool with exists() and generate() methods can be installed in site_scons/site_tools/toolname.py. 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 a build_id method:

      def build_id():
         """Return a build ID (stub version)"""
         return "100"
  

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()
  

If you have a machine-wide site dir you'd like to use instead of ./site_scons, use the --site-dir option to point to your 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.

22.1. A Simple Scanner Example

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_contents()
          return include_re.findall(contents)
    

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_contents()
            includes = include_re.findall(contents)
            return 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')
    

23.1. The Repository Method

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.

23.2. Finding source files in repositories

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
    

23.3. Finding #include files in repositories

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
      

23.4. Finding the SConstruct file in repositories

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.

23.5. Finding derived files in repositories

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.

23.6. Guaranteeing local copies of files

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

24.1. Configure Contexts

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.

24.2. Checking for the Existence of Header Files

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()
    

24.3. Checking for the Availability of a Function

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('-Dstrcpy=my_local_strcpy')
    env = conf.Finish()
    

24.4. Checking for the Availability of a Library

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'):
        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.

24.5. Checking for the Availability of a typedef

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()
    

24.6. Adding Your Own Custom Checks

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 ok if the check succeeds and failed 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... failed
    MyLibrary is not installed!
    

If MyLibrary is installed, the output will look like:

    % scons
    scons: Reading SConscript file ...
    Checking for MyLibrary... failed
    scons: done reading SConscript
    scons: Building targets ...
        .
        .
        .
    

24.7. Not Configuring When Cleaning 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... ok
    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
    

25.1. Specifying the Shared Cache Directory

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

25.2. Keeping Build Output Consistent

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.

25.3. Not Using the Shared Cache for Specific Files

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
    

25.4. Disabling the Shared 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
    

25.5. Populating a Shared Cache With Already-Built Files

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.

25.6. Minimizing Cache Contention: the --random Option

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 f1.o -c f1.c
      cc -o f2.o -c f2.c
      cc -o f3.o -c f3.c
      cc -o f4.o -c f4.c
      cc -o f5.o -c f5.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:

       Program('prog',
               ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c'])

       SetOption('random', 1)
       Program('prog',
               ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c'])
    

27.1. Building Java Class Files: the Java Builder

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.

27.2. How SCons Handles Java Dependencies

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
    

27.3. Building Java Archive (.jar) Files: the Jar Builder

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
    

27.4. Building C Header and Stub Files: the JavaH Builder

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
    

27.5. Building RMI Stub and Skeleton Class Files: the RMIC Builder

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.

28.1. Verifying the Python Version: the EnsurePythonVersion Function

Although the SCons code itself will run on any Python version 1.5.2 or later, you are perfectly free to make use of Python syntax and modules from more modern versions (for example, Python 2.4 or 2.5) 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
    

28.2. Verifying the SCons Version: the EnsureSConsVersion Function

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
    

28.3. Explicitly Terminating SCons While Reading SConscript Files: the Exit Function

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.

28.4. Handling Nested Lists: the Flatten Function

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

29.1. Why is That Target Being Rebuilt? the --debug=explain Option

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.

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
      % edit file2.c
          [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
      % edit hello.h
          [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.)

29.2. What's in That Construction Environment? the Dump Method

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>, '_InternalInstallAs': <function InstallAsBuilderWrapper at 0x700000>},
        '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'],
        'DSUFFIXES': ['.d'],
        'Dir': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'Dirs': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'ENV': {'PATH': '/usr/local/bin:/opt/bin:/bin:/usr/bin'},
        'ESCAPE': <function escape at 0x700000>,
        'File': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'IDLSUFFIXES': ['.idl', '.IDL'],
        'INSTALL': <function copyFunc at 0x700000>,
        'LATEXSUFFIXES': ['.tex', '.ltx', '.latex'],
        '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>,
        'RDirs': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'SCANNERS': [],
        'SHELL': 'sh',
        'SHLIBPREFIX': '$LIBPREFIX',
        'SHLIBSUFFIX': '.so',
        'SHOBJPREFIX': '$OBJPREFIX',
        'SHOBJSUFFIX': '$OBJSUFFIX',
        'SPAWN': <function spawnvpe_spawn at 0x700000>,
        'TEMPFILE': <class SCons.Platform.TempFileMunge at 0x700000>,
        '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__)}',
        '__RPATH': '$_RPATH',
        '_concat': <function _concat at 0x700000>,
        '_defines': <function _defines at 0x700000>,
        '_stripixes': <function _stripixes at 0x700000>}
      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': {'_InternalInstall': <function InstallBuilderWrapper at 0x700000>, 'Object': <SCons.Builder.CompositeBuilder instance at 0x700000>, 'PCH': <SCons.Builder.BuilderBase instance at 0x700000>, 'RES': <SCons.Builder.BuilderBase instance at 0x700000>, 'SharedObject': <SCons.Builder.CompositeBuilder instance at 0x700000>, 'StaticObject': <SCons.Builder.CompositeBuilder instance at 0x700000>, '_InternalInstallAs': <function InstallAsBuilderWrapper at 0x700000>},
        'CC': 'cl',
        'CCCOM': <SCons.Action.FunctionAction instance at 0x700000>,
        'CCCOMFLAGS': '$CPPFLAGS $_CPPDEFFLAGS $_CPPINCFLAGS /c $SOURCES /Fo$TARGET $CCPCHFLAGS $CCPDBFLAGS',
        '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'],
        'CXX': '$CC',
        'CXXCOM': '$CXX $CXXFLAGS $CCCOMFLAGS',
        'CXXFILESUFFIX': '.cc',
        'CXXFLAGS': ['$CCFLAGS', '$(', '/TP', '$)'],
        'DSUFFIXES': ['.d'],
        'Dir': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'Dirs': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'ENV': { 'INCLUDE': 'C:\\Program Files\\Microsoft Visual Studio/VC98\\include',
                 'LIB': 'C:\\Program Files\\Microsoft Visual Studio/VC98\\lib',
                 'PATH': 'C:\\Program Files\\Microsoft Visual Studio\\Common\\tools\\WIN95;C:\\Program Files\\Microsoft Visual Studio\\Common\\MSDev98\\bin;C:\\Program Files\\Microsoft Visual Studio\\Common\\tools;C:\\Program Files\\Microsoft Visual Studio/VC98\\bin',
                 'PATHEXT': '.COM;.EXE;.BAT;.CMD',
                 'SystemRoot': 'C:/WINDOWS'},
        'ESCAPE': <function escape at 0x700000>,
        'File': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'IDLSUFFIXES': ['.idl', '.IDL'],
        'INCPREFIX': '/I',
        'INCSUFFIX': '',
        'INSTALL': <function copyFunc at 0x700000>,
        'LATEXSUFFIXES': ['.tex', '.ltx', '.latex'],
        'LIBPREFIX': '',
        'LIBPREFIXES': ['$LIBPREFIX'],
        'LIBSUFFIX': '.lib',
        'LIBSUFFIXES': ['$LIBSUFFIX'],
        'MAXLINELENGTH': 2048,
        'MSVS': {'VERSION': '6.0', 'VERSIONS': ['6.0']},
        'MSVS_VERSION': '6.0',
        'OBJPREFIX': '',
        'OBJSUFFIX': '.obj',
        'PCHCOM': '$CXX $CXXFLAGS $CPPFLAGS $_CPPDEFFLAGS $_CPPINCFLAGS /c $SOURCES /Fo${TARGETS[1]} /Yc$PCHSTOP /Fp${TARGETS[0]} $CCPDBFLAGS $PCHPDBFLAGS',
        'PCHPDBFLAGS': ['${(PDB and "/Yd") or ""}'],
        'PLATFORM': 'win32',
        'PROGPREFIX': '',
        'PROGSUFFIX': '.exe',
        'PSPAWN': <function piped_spawn at 0x700000>,
        'RC': 'rc',
        'RCCOM': <SCons.Action.FunctionAction instance at 0x700000>,
        'RCFLAGS': [],
        'RDirs': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>,
        'SCANNERS': [],
        'SHCC': '$CC',
        'SHCCCOM': <SCons.Action.FunctionAction instance at 0x700000>,
        'SHCCFLAGS': ['$CCFLAGS'],
        'SHCFLAGS': ['$CFLAGS'],
        'SHCXX': '$CXX',
        'SHCXXCOM': '$SHCXX $SHCXXFLAGS $CCCOMFLAGS',
        'SHCXXFLAGS': ['$CXXFLAGS'],
        'SHELL': None,
        'SHLIBPREFIX': '',
        'SHLIBSUFFIX': '.dll',
        'SHOBJPREFIX': '$OBJPREFIX',
        'SHOBJSUFFIX': '$OBJSUFFIX',
        'SPAWN': <function spawn at 0x700000>,
        'STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME': 1,
        'TEMPFILE': <class SCons.Platform.TempFileMunge at 0x700000>,
        'TEMPFILEPREFIX': '@',
        'TOOLS': ['msvc', '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__)}',
        '_concat': <function _concat at 0x700000>,
        '_defines': <function _defines at 0x700000>,
        '_stripixes': <function _stripixes at 0x700000>}
      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 ...
      { 'INCLUDE': 'C:\\Program Files\\Microsoft Visual Studio/VC98\\include',
        'LIB': 'C:\\Program Files\\Microsoft Visual Studio/VC98\\lib',
        'PATH': 'C:\\Program Files\\Microsoft Visual Studio\\Common\\tools\\WIN95;C:\\Program Files\\Microsoft Visual Studio\\Common\\MSDev98\\bin;C:\\Program Files\\Microsoft Visual Studio\\Common\\tools;C:\\Program Files\\Microsoft Visual Studio/VC98\\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.
    

29.3. What Dependencies Does SCons Know About? the --tree Option

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.

29.4. How is SCons Constructing the Command Lines It Executes? the --debug=presub Option

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
    

29.5. Where is SCons Searching for Libraries? the --debug=findlibs Option

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
    

29.6. Where is SCons Blowing Up? the --debug=stacktrace Option

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: *** Source `prog.c' not found, needed by target `prog.o'.  Stop.
    

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: *** Source `prog.c' not found, needed by target `prog.o'.  Stop.
      scons: internal stack trace:
        File "bootstrap/src/engine/SCons/Job.py", line 198, in start
        File "bootstrap/src/engine/SCons/Script/Main.py", line 169, in prepare
        File "bootstrap/src/engine/SCons/Taskmaster.py", line 184, in prepare
        File "bootstrap/src/engine/SCons/Executor.py", line 171, in prepare
    

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

29.7. How is SCons Making Its Decisions? the --taskmastertrace Option

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:      adjusting ref count: <pending    1   'prog'>
      Taskmaster:     Considering node <no_state   0   'prog.o'> and its children:
      Taskmaster:        <no_state   0   'prog.c'>
      Taskmaster:        <no_state   0   'inc.h'>
      Taskmaster:      adjusting ref count: <pending    1   'prog.o'>
      Taskmaster:      adjusting ref count: <pending    2   'prog.o'>
      Taskmaster:     Considering node <no_state   0   'prog.c'> and its children:
      Taskmaster: Evaluating <pending    0   'prog.c'>
      
      Taskmaster: Looking for a node to evaluate
      Taskmaster:     Considering node <no_state   0   'inc.h'> and its children:
      Taskmaster: Evaluating <pending    0   'inc.h'>
      
      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'>
      cc -o prog.o -c -I. prog.c
      
      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'>
      cc -o prog prog.o
      
      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.