We used SCons as our build system at Axham Games. SCons is implemented as a Python script and a set of modules. Configuration files in SCons are also Python scripts which are executed; this makes for a very potent build system for you have all of the power of Python, its modules and extensions available for use in your build system.
In this post, I’ll focus on the object model for our build system which essentially treats each group of libraries as a component. If warranted and there’s sufficient interest, I’ll get into details of the entire system in a future follow up post.
- modularity and ease of extension; primarily be able to add libraries with minimum addition to the build system
- ability to build on multiple platforms without requiring additional steps
- flexibility to be able to swap library versions with minimal alterations
- override build parameters at the command line
Each set of libraries in the build system is treated as a single component. One of the major issues I ran into early on when compiling for multiple platforms and architectures, particularly when using different compiler toolchains, was that they all followed vastly different and inconsistent naming conventions. I found this to be true even for the same set of libraries built using the same compiler toolchain where only the platform differed. The most common example is the prefixing of “lib” on POSIX systems. On Windows, some libraries get built out on POSIX emulation toolchains (like mingw-gcc) with library naming conventions similar to POSIX systems, while some libraries do not.
All sets of libraries used typically have a fixed set of properties viz. include path, library path and libraries to statically or dynamically link to. So, in essence we can treat each set of libraries like boost or Ogre3d as a single component for the purposes of our build system.
Boost as an Example
Let us take boost as an example for the purposes of explaining the usage of the object model. Boost, has a rather convoluted naming convention (with good reason, probably) for its libraries, wherein the boost version is embedded in the middle of the library name with a mixture of underscores and hyphens. e.g.
Let’s break this example name down into its constituent parts:
- lib – this indicates that it’s a library of some sort, could be static, dynamic or a stub library you link to use a dynamic library.
- boost – name of the library “group” it’s a part of
- thread – the actual library, in this case it’s a thread library
- mgw48 – compiler toolchain and version, in this case, mingw gcc 4.8
- mt – multi-threaded
- d – debug
- 1_55 – boost version
- dll.a – stub library to link to use the dynamic library