Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.

NOTE: This page was edited by hand into its current format by cutting-and-pasting a copy of the page that was saved at It is entirely possible that some formatting or other errors crept in during the editing process. If you notice any errors, please correct them.

This document describes the build used on the Bombyx Project in a way that is a tutorial of SCons. It covers various advanced topics in a bit of detail, and gives pointers to other documents that describe the technique in more detail. Some of the things shown here are "voodoo" and probably not standard. If you find a better way to do something, then please contact me with your suggestion.


The great thing about SCons is that it is very flexible, but still very easy to use. The one bad thing is that there are few examples to get a person started. You can read the man page, but there's nothing that really shows you some best practices to follow at first. After working with SCons for a while, I've come up with a fairly well laid out build environment that works on multiple platforms with very little configuration. It follows a logical configuration where SCons can configure itself based on information it finds. It also breaks out the "configuration" of the build (such as where libraries are, and what header file paths are needed) from the actual Environment object specification. This is important when supporting multiple developers who use different systems, or when building on heterogeneous systems. This lets the user configure the build for the target system without modifying the operation of the build.

Key Terms

I'll be filling these in as I find things that I need to explain a bit better.

Build Design

The goal of the Bombyx build system is to create a logical build configuration that will make it very easy to build the software on multiple systems in a consistent manner. It also tries to separate the different levels of configuration from each other to allow for a modular design. Finally, it has a couple of advanced features which might interest you.

I also wanted to make it easier to localize builds in the right place, and "autoconfigure" from the common config scripts found in many libraries (like, GTK+ has gtk-config, and FLTK has fltk-config).

To accomplish this, I have the following:

The next section covers this layout in detail and gives some of the benefits of it.

Layout & Structure

First, we need to configure the locations of the different files necessary for the build, and describe what each does:

The italicized things are directories (root, src, build, etc.) the other things are files used SCons in the build (SConstruct,, and the .h and .cpp are example source files. The root directory is just whatever you call the directory where you do your work.

The first thing to notice is that, in addition to the SConstruct file in the ROOT/ directory, there's two more files, "" and "". The file has basic configuration information that each developer would probably need to modify on different platforms. The file contains any support functions you need that don't fit into the SCons system. I have a few nice little tricks in this file that make builds more automatic.

The next thing of importance is the build/ directory and its contents. The build/ directory is where the program is built for each target system, using additional configuration information necessary for that system (in the SConscript file there). This build directory is switched automatically by a function in the file depending on the platform indicated by Python.

Finally, there's the tests/ and src/ directories, which hold the source code for the system. The tests/ directory is currently not used quite yet, but it will eventually hold Unit Tests from the CxxTest project which this build configuration will run automatically and produce reports. The src/ directory just holds the source for your system. You can organize this directory how you wish, and I may have a configuration in the future that will allow SCons scan this directory and build different targets depending on how it is structured.

Based on this, here's an example of what happens when you run SCons from the ROOT/ directory on a Mac OS X (Darwin) system:

  1. SCons reads the SConstruct file
  2. SConstruct imports the contents of and
  3. SConstruct uses a function (SelectBuildDir) from to figure out what the target build directory should be.

  4. The SelectBuildDir function does some magic (explained later) to figure out that the darwin target should be built in ROOT/build/darwin.

  5. SConstruct switched to ROOT/build/darwin and loads the SConscript file there

  6. This final SConscript file makes any last minute changes necessary to build on the target system and then starts the build like normal.

While this may seem complex at first, it has a few very big advantages over just a single SConstruct build:

  1. If you want to change the configuration for a build, you just edit
  2. If something weird needs to be done on a target platform, you just edit the ROOT/build/<target>/SConscript file.

  3. You shouldn't have to edit the ROOT/SConstruct file after you have it configured (even when you switch to a new target).
  4. Adding a new target is as easy as just making a new directory in ROOT/build and adding an SConscript file with the required changes.

  5. SCons will default to the ROOT/build/default directory if present, letting you put a generic SConscript file for any unkown targets.

  6. The build is localized to a single directory, which makes it a bit easier to organize multi-target builds.

Finally, I have done most of the work for you, so you should just have to modify the files a bit to get things going and then you're done.

Support Library

The file has some functions that the SConstruct build uses to do some work. These files really don't have anything to do with the current build setup, and only clutter the SConstruct files if you put them there. By moving these support routines into your own file, you localize them and make them easier to maintain. It also keeps the SConstruct files clean from anything unecessary.

The code for the first function used in Bombyx is very interesting:

def ParseConfig(env,command,options):
    env_dict = env.Dictionary();
    static_libs = []

    # setup all the dictionary options
    if not env_dict.has_key('CPPPATH'):
        env_dict['CPPPATH'] = []

     if not env_dict.has_key('LIBPATH'):
         env_dict['LIBPATH'] = []

     if not env_dict.has_key('LIBS'):
         env_dict['LIBS'] = []

     if not env_dict.has_key('CXXFLAGS'):
         env_dict['CXXFLAGS'] = []

     if not env_dict.has_key('LINKFLAGS'):
         env_dict['LINKFLAGS'] = []

     # run the config program to get the options we need
     full_cmd = "%s %s" %  (WhereIs(command), join(options))

     params = split(os.popen(full_cmd).read())

     i = 0
     while i < len(params):
         arg = params[i]
         switch = arg[0:1]
         opt = arg[1:2]
         if switch == '-':
             if opt == 'L':
             elif opt == 'l':
             elif opt == 'I':
             elif arg[1:] == 'framework':
                 flags = [env_dict['LINKFLAGS']]
                 env_dict['LINKFLAGS'] = join(flags)
                 i = i + 1
         i = i + 1

     return static_libs

What this function does is take an SCons Environment object to work on, a command to run which should output compiler options, and a list of options to pass to the command. It then takes the standard output from this command, parses it, and modifies the Environment appropriately so that the library will work. It is used like so:

   1 ParseConfig(env, "fltk-config","--static")

The function then runs "fltk-config --static", takes the output that the script gives (which are the compiler options needed to use FLTK), and modifies the Environment object env so that it reflects those options. Since SCons doesn't allow you to specify static libraries in the list of libraries, it returns the statis libraries so you can append them to the build sources in your targets.

/!\ Bombyx currently doesn't use this function since I've switched to using FOX, which doesn't have a configure script. Still, it's a very useful function, feel free to steal it.

The next function simple takes a build directory and a platform (if you don't give a platform, it will ask Python what it thinks the platform is). It then for a build directory under ROOT/build that matches the platform name. If a platform is not found then it defaults to the ROOT/build/default directory, so that you can at least attempt building on unknown platforms.

   1 def SelectBuildDir(build_dir, platform=None):
   3     # if no platform is specified, then default to sys.platform
   4     if not(platform):
   5         platform = sys.platform
   7     print "Looking for build directory for platform '%s'" % platform
   9     # setup where we start looking at first
  10     test_dir = build_dir + os.sep + platform
  11     default_dir = build_dir + os.sep + 'default'
  14     # we look for a directory named exactly after the
  15     # platform so that very specific builds can be done
  16     if os.path.exists(test_dir):
  17         # make sure it is a directory
  18         target_dir = test_dir
  19     else:
  20         print "Exact match not found, finding closest guess"
  22         # looks like there isn't an exact match
  23         # find the closest matching directory
  24         dirs = os.listdir(build_dir)
  25         found_match = 0
  26         for dir in dirs:
  27             if platform.find(dir) != -1:
  28                  # found a match (hopefully the right one)
  29                  target_dir = build_dir + os.sep + dir
  30                  found_match = 1
  31                  break
  32         if not(found_match):
  33             print "No match found, looking for 'default' directory"
  34             # looks like this platform isn't available
  35             # try the default target
  36             if os.path.exists(default_dir):
  37                 target_dir = default_dir
  38             else:
  39                 # bad, nothing is available, tell the user
  40                 print "No build directories found for your platform '%s'" % platform
  41                 return None
  43     print "Found directory %s, will build there" % target_dir
  44     return target_dir

This function is the core of the Bombyx build setup, as it allows you to create different build target directories and easily configure them. I would like to add the ability to select the closest matching build directory if an exact match isn't found. So, if netbsd doesn't exist, then it will try bsd, and if that isn't found then default is chosen.

The next file is simply a nice thing to have if you absolutely must have a file. SCons doesn't give good error messages when a missing library or something (it just lets the compiler do it). Using this function let's you require a particular set of files before continuing. It exits whenever it encounters a file not found so that the user can correct the problem.

   1 def RequireFiles(files, found_files, search_path):
   2     i = 0
   3     for file in found_files:
   4         if not(file):
   5             print "ERROR:  Could not find the %s file in:" % files[i]
   6             print "ERROR:  \t%s" % search_path
   7             print "ERROR:  Edit the file and add"
   8             print "ERROR:  the location of this file to the appropriate variable."
  10             sys.exit(1)
  12         else:
  13             i = i + 1

These functions are hidden away in the so that the SConstruct files are easier to understand and modify later.

Configuration File

The next part of this build is the file, which contains the variables that all targets need, usually consisting of variable assignments. Here's the from Bombyx:

   1 import os
   3 ## where we find libsilcclient.a, libsilc.a, and other STATIC libraries
   4 lib_search_path = ['/lib','/usr/lib','/usr/local/lib','/usr/local/silc/lib']
   6 ## where we should find things to include
   7 include_search_path =  ['/usr/local/silc/include','#src']
   9 ## These are our source files
  10 sources = ['ChatWindow.cpp', 'dbg.cpp', 'FXBroadcast.cpp', 'MainWindow.cpp', 'Server.cpp','main.cpp']
  11 test_sources = ['ChatWindow.cpp', 'dbg.cpp', 'FXBroadcast.cpp', 'MainWindow.cpp', 'Server.cpp','#tests/testrunner.cpp']
  13 # update the environment with options from fltk-config
  14 static_libs = ['/usr/local/lib/libFOX.a']
  16 #### You should not change these.  These are only here
  17 #### If you want to start your own build setup with a
  18 #### different layout than mine.
  19 source_base_dir = 'src'
  20 build_base_dir = 'build'
  21 target_name = 'bombyx'

As you can see, this is pretty simple stuff. The nice thing is that even the source_base_dir, build_base_dir, and target_name variables are configurable. This lets potential users change the layout of the directory structure if they don't like the name 'src' and 'build'.

The target_name variable is probably not useful if you need to compile multiple target files (programs, libraries, etc.). Right now Bombyx just has one target file (bombyx) and eventually a test target. I'll have to develop a way that you can configure multiple sources->target configurations. But, this is good enough for now, and any more would probably just confuse things.

The key to this file is that, when you go to a different target platform, you can just go into this file and make the changes you need easily. Also, if you need to add a new source file, you just edit the file again.

/!\ Currently the test_sources is only used for my development of the testing framework for Bombyx. I'll be updating this document with that when I'm done with it. For now, just ignore.

Top Level SConstruct File

Now that all the support stuff is out of the way, I'll cover the top level SConstruct file. This file acts as the major configuration entry point, and coordinates all the other SConstruct files. It does as much configuration as it can for all target platforms, then it switches to the platform specific SConscript file for each platform in ROOT/build.

The top level SConstruct file follows:

   1 import os
   2 import sys
   3 from build_support import *
   4 from build_config import *
   7 # Setup some of our requirements
   9 env = Environment()
  11 # setup the include paths where FLTK and silc should live
  12 env.Append(CPPPATH=include_search_path)
  13 env.Append(LIBS=['m', 'jpeg', 'png', 'tiff', 'z', 'Xext', 'X11'])
  14 env.Append(LIBPATH=['/usr/X11R6/lib'])
  16 # variables the sub build directories need
  17 Export('env', 'sources', 'static_libs', 'test_sources')
  20 # start the build
  21 target_dir = '#' + SelectBuildDir(build_base_dir)
  22 SConscript(target_dir + os.sep + 'SConscript')
  23 BuildDir(target_dir, source_base_dir, duplicate=0)
  24 Default(target_dir + os.sep + target_name)
  26 # this sets up an alias for test that will compile the unit tests
  27 # into the resulting testrunner program.
  28 env.Alias('test', target_dir + os.sep + 'testrunner')

You should be careful of line #23 since it contains the "duplicat=0" argument to ?BuildDir. This tells SCons to not copy files to the platform build dir (like .h and .cpp stuffs) when it does the build. This is important because the scons -c command does not properly clean these files out, and when there are errors you'll get the line numbers from the copied files and not the actual files. This makes it really difficult to find the errors automatically in things like Emacs or Vim.

This file imports the stuff it needs, sets up the basics of the Environment variable, exports the necessary variables to the platform SConscript file, and then switches to that file. It also has some stuff specific to the Unit Testing framework I'm developing for SCons which we'll ignore.

I'll cover this file line by line as it is the general culmination of what we've covered so far:

1 to 4

Imports some Python libraries and the and files to get the required configuration variables and support functions. Notice it uses a from statement to to the imports for and so that they can be refered to directly (it's inconvenient to have to say build_config.build_dir).


Sets up the Environment object env that we'll use to configure the build.

12 to 14

Appends some additional information that all targets need (targets that don't need it can remove them in the platform SConscript file).


Exports the variables that each platform SConscript file will need to complete the build configuration. These are later Imported by the platform SConscript file.


This runs the ?SelectBuildDir function defined in the file to figure out what the platform build directory should be.


Tells SCons to use continue processing with the SConscript file in the platform build directory.


Tells SCons to use the build directory that SelectBuildDir returns. The duplicate=0 says not to copy the files from source to the build dir when it builds. This has some consequences, but gives you better error messages.


Sets up the default target to whatever we described in the file. This is only a convenience so that people can type "scons" without having to say "scons build/darwin/bombyx".


This is for the future Unit Test running setup. It creates an alias from "test" to the testrunner program. This lets users do "scons test" and have the testrunner build. This currently works, but I need to add running the test program and also building reports.

This is pretty straight forward and demonstrate some of the features of SCons. You could move things from as you see fit. For example, if I wanted to have multiple targets, I would probably want to move them to this file where I have more flexibility ( usually just has variable assignments, where SConstruct files can use all of SCons).

Platform SConscript Files

Next I'll cover the most complicated platform SConscript file, that for the Mac OS X platform. This platform is interesting since it has such a wildly different installation of GCC, which defaults to strange locations and uses GCC 2.95.2 by default. This requires us to make major changes to the environment in the platform SConscript file. Here's the file:

   1 # import these variables from the parent build script
   2 Import('env', 'sources', 'static_libs', 'test_sources')
   4 # add the specific things needed by MacOSX GCC
   5 macosx_incs=[]
   7 env.Replace(CXX='g++3')
   8 env.Replace(CC='gcc3')
   9 env.Replace(CPP='gcc3')
  10 env.Replace(LINK='g++3')
  11 env.Append(CXXFLAGS='-DDBG_ENABLED')
  12 env.Append(CPPPATH=macosx_incs)
  15 # add the bombyx target to the environment
  16 env.Program(target='bombyx', source=sources + static_libs)
  18 # add the testrunner target to the environment
  19 env.Program(target='testrunner', source=test_sources + static_libs)

We'll cover this file line by line also so that you can understand each thing going on. It's pretty simple, and I'll demonstrate a regular build for the Linux platform later.


Imports the variables the the root SConstruct file Exported previously (go look, this is really, really important in this build setup). Make sure you understand this concept. You can call Export() from one SConstruct, switch to another SConscript and then Import those same (or less) variables.

7 to 12

We just replace some variables that Mac OS X needs configured differently. This is an example of modifying what the root SConstruct file thinks is correct. Usually you won't have to do this, but Mac OS X is just weird. You could also add extra libraries and other options here.


This adds a Program target for the 'bombyx' program and sets the sources to the sources and static_libs variables. The sources and static_libs variables were variables we set in the file, which were exported by the root SConstruct file (and then imported by us). I decided not to use the target I configured in the to demonstrate that you can change it.


This file sets up a Program target for 'testrunner' that is used to run the Unit Tests. it works the same as what we did in lin 16.

Pretty simple huh? Now, the nice thing is that, when you hit another platform that is similar to Mac OS X (NeXT?), you just make a new directory, copy this SConscript file into it, and make any changes you need. You shouldn't have to edit anything else.

When you run SCons with this command:


Then SCons will read the,, ROOT/Sconstruct, and then the ROOT/build/darwin/SConscript file to figure out how to build your program. After that, it just builds it as specified and puts the results in the ROOT/build/darwin directory.

Just for completeness, here's the build file for Linux:

   1 # import these variables from the parent build script
   2 Import('env', 'sources', 'static_libs')
   4 # add the bombyx target to the environment
   5 env.Program(target='bombyx', source=sources + static_libs)

That's it. You just import the stuff you exported and setup your targets. Actually, this is so common that you could just put this file in the ROOT/build/default directory, and then you'll only need to create a directory for the strange platforms.

Modifying The Setup

If you want to modify this setup, just make sure you understand it and then change the files that are appropriate. This list will help guide you in where to go to make major changes. If you just want to use the setup, then you should only need to change the ROOT/ file, and create platform specific files in the ROOT/build directory.






Once you figure out where you need to make your changes, pick a familiar platform and get your build to work with it. Once it works for that platform, go onto another and try configuring it by just creating a platform SConscript file. If you need to make changes to the other files, then see if the changes are necessary to your already working platforms. If not, try using the SCons methods mentioned in the man page to modify the build in the platform SConscript file.

Further Information

I hope this document helps you get some work done. This configuration is a bit complicated, but once you grok it, it is very nice to work with. There are some bugs in it (which I've noted with /!\ symbols) but these are minor and only affect a few platforms.

If you want to get this build, then you can go to the Bombyx site and check out (anonymously) the CVS root. You'll need to check-out the BOMBYX_MS1 branch to get these changes. If you don't know how to do this, then just wait a while and I'll make a release with all the changes in it. Until then, all the code in the Bombyx build is in this document. You could just hit the "Edit" link below and cut and paste the code right out (it's inlined verbatim).

If you have any suggestions for improvements, or questions, then just e-mail me at Enjoy!

AdvancedBuildExample (last edited 2008-03-12 02:47:03 by localhost)