This is the seventh post in my SCons series. The topic of this post is getting rid of the last bit of overhead in SConscript files – the Import('*') line.

According the the SCons user guide, a SConscript files needs to Import('...') shared symbols. It’s possible to import all exported symbols with Import('*'). This is the method I used in previous episodes to make shortcuts available in module-level SConscript files

Perhaps you’re fine with this little remaining overhead in every SConscript file. After all, it’s not such a big deal. With the wildcard syntax, you will never need to go over old SConscript files and update their import list when you add a new shortcut.

If you prefer your SConscript files as minimal as possible, here’s a dirty little hack I use. Instead of passing the shortcuts dictionary to a delegated SConscript file using the exports argument, I modify the _SConscript.GlobalDictdirectly before invoking the SConscript() function.

Using my example project, you may recall from the previous episode how the delegation looks like:

def process_module(self, module):
    print 'scons: |- Reading module', module, '...'
    # Execute the SConscript file, with variant_dir set to the
    #  module dir under the project flavored build dir.
    self._env.SConscript(
        sconscript_path,
        variant_dir=os.path.join(self._env['BUILDROOT'], module),
        exports=shortcuts)

The hack is a minor modification of this snippet:

def process_module(self, module):
    print 'scons: |- Reading module', module, '...'
    # Execute the SConscript file, with variant_dir set to the
    #  module dir under the project flavored build dir.
    SCons.Script._SConscript.GlobalDict.update(shortcuts)
    self._env.SConscript(
        sconscript_path,
        variant_dir=os.path.join(self._env['BUILDROOT'], module))

The result of the hack is that the shortcuts are injected directly into the global dictionary. This means that these symbols are available in SConscript files, without any call to Import(..)!

As always, the entire project is available on my GitHub scons-series repository. Feel free to use / fork / modify. If you do, I’d appreciate it if you share back improvements.

See the scons tag for more in my SCons series.

This is the sixth post in my SCons series. The topic of this post is building reusable infrastructure that can extremely simplify your module-level SConscript files.

Starting with the first non-trivial SCons project, the module-level SConscript files contained too much repetitive code. The goal of this enhancement is to go back to minimalistic SConscript files. The objective is to let the developer define the module-level targets with minimal code, and no hassle.

I continue using the same C++ project that I introduced in the basic example. In this post I present SCons shortcuts that are available in module-level SConscript files. These shortcuts are Python functions that take care of dirty details behind the scenes.

The final result is available on my GitHub scons-series repository.

This is the fifth post in my SCons series. The topic of this post is improving the previous multi-flavor project via terminal integration.

It can be a hassle to handle multi-flavor projects. In the multi-flavor project post, I suggested a solution to simplify the multi-flavor build process. Using that solution, you just run scons flavor_name to build a specific flavor. But there’s still room for improvement! If you want to run a program you just built, you still need to specify the path to the flavored executable.

For example, say you built a project with a program named say_hi in the module hello. You built it by running scons debug. To run it you execute ./build/debug/hello/say_hi. It can be a hassle to write ./build/debug over and over. Even worse, it’s the first time you need to know about the layout of the build directory. Up until now, such details were nicely hidden in the config file.

In addition, you may often want to work with just one flavor. You may be developing a new feature, and you want to only build and run the debug flavor. If you run scons without the debug argument, all flavors will be built. This can be annoying and time consuming.

In this post, I suggest a helper script to make things simpler. The purpose of the script is to allow you to activate a flavor in a terminal session. While a flavor is active, magical things happen:

1. Running scons with no arguments builds only the active flavor.
2. The executable programs of the active flavor can be executed more conveniently.
3. The active flavor is indicated in the terminal prompt.

The final result is available on my GitHub scons-series repository. In the rest of this post I go into the details of the helper script and related changes.

This is the fourth post in my SCons series. The topic of this post is setting up a multi-flavor C++ project using SCons, with a separate build directory. By “flavor”, I mean something like debug vs. release.

In C++ projects, it is common to build multiple variants, or flavors, of the project. A debug flavor may build more quickly, and contain debug symbols. A release flavor may perform optimizations for runtime or other metrics. The different flavors serve different purposes, and they all can co-exist. The developer may choose which flavor(s) to build and run as she pleases.

In this post, I show how to use SCons to manage multiple flavors in a C++ project. My requirements from flavor support in a SCons-powered C++ project:

1. Define flavor profiles easily. Allow to customize construction parameters per-flavor. Support common parameters that can be overridden by flavors.
2. Support flavor-specific build directory. Build outputs should reside under their flavor build directory. Multiple flavors can co-exist at the same time, without interfering with each other. Incremental builds can be done per-flavor.
3. Let the developer choose what to build. Allow choosing one flavor, all flavors, or any subset. Syntax should be simple and intuitive.
4. The developer can execute built programs at any flavor she wants.

I add multi-flavor support on top of the previous episode in the series.

The final result is available on my GitHub scons-series repository. In the rest of this post I go into the details of what I came up with.

This is the third post in my SCons series. The topic of this post is setting up a multi-module C++ project using SCons, with a separate build directory.

In previous posts in the series I introduced the SCons open source build tool, and described a simple C++ example project that uses SCons.

In this post I use the exact same C++ project from the basic example. I rewrite the build scripts, using SCons, to achieve the following properties:

1. Divide the project into distinct modules. A module maps to a directory in the project tree. Each module contains a SConscript file, describing the targets included in that module.
2. Separate the build output directory from the module source code directories. I like my project tree clean and tidy, without object files scattered between source files.
3. Allow build targets in modules to refer to other targets in other modules easily. This is required, for example, when a program in one module uses functions from a static library in another module.

The final result is available on my GitHub scons-series repository. In the rest of this post I explain the details of what I came up with.