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.