SCons Build-System

^{this section is based on the introductory pages on the SCons Wiki}

When SCons starts building the project, it creates its own environment with dependency trees, helper functions, builders and other stuff. The SCons environment is created in memory and some parts of it are saved to disk to speed up things on the next start. The definition of the build happens within this artificial build environment. This often confuses people who used Makefiles, where environment is actually the System Environment.

the familiar operating system container with environment variables such as PATH, HOME etc. It is usually accessible via os.environ mapping in Python and therefore in SCons too. SCons doesn’t import any settings from System Environment automatically (like flags for compilers, or paths for tools), because it’s designed to be a cross platform tool with predictable behaviour. That’s why, if you rely on any system PATHs or environment variables — you need to extract those settings explicitly in your build definition.

when SCons executes, it performs a build definition python script written by the user. By convention, this main script is called SConstruct and is located in the root of the source tree. It is a full featured Python module executed within a specifically prepared environment.

these files are also SCons scripts, but they are placed in subdirectories of the project. Typically they are used to organize hierarchical builds and are included from the main SConstruct file from the project root. Often, all of the actual build definitions reside in SConscript files in the sub-trees of the project.

The SCons buildsystem revolves around the metaphor of a Builder. This is a SCons object that you explicitly invoke from the scripts to define that there is something to build, transforming a source into a target. So the target depends on the sources, and typically those source nodes were created by previous builder invocations. The power of SCons is in the fact that dependencies are tracked automatically. When source files change, the system is able to derive which targets to rebuild.

when defining a builder, SCons relies on modular scanner components to “understand” the source of the build step. They may scan source files to discover additional dependencies referenced inside. Thus, SCons comes with built-in knowledge about the source files and artefacts to be created by a typical build, and further types can be added through plug-ins.

any further, external component that adds Builders, Scanners and other helpers to SCons environments for use within scripts. There are special tools for configuring the platform to detect libraries and further requirements. Relying on those tools. the build environment will be outfitted to reflect the needs of the specific build. Sub-environments with special configuration may be created.

any node or “build step” encountered through the definition of the build is a target. The actual build will be triggered by requesting a target, which typically might be just an executable known to reside at some location in the tree. Special alias targets may be defined, based on other targets, to trigger off standard build situations. Especially, a default target may be defined.

Within our build system, we build upon the power of the Python programming language to create abstractions tailored to the needs of our project. Located in the admin/scons subdirectory, you’ll find a collection of Python modules to provide these building blocks.