Scons Build System

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.

Primary Objectives

  1. modularity and ease of extension; primarily be able to add libraries with minimum addition to the build system
  2. ability to build on multiple platforms without requiring additional steps
  3. flexibility to be able to swap library versions with minimal alterations
  4. override build parameters at the command line

Object Model

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. libboost_thread-mgw48-mt-d-1_55.dll.a

Let’s break this example name down into its constituent parts:


  1. 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.
  2. boost – name of the library “group” it’s a part of
  3. thread – the actual library, in this case it’s a thread library
  4. mgw48 – compiler toolchain and version, in this case, mingw gcc 4.8
  5. mt – multi-threaded
  6. d – debug
  7. 1_55 – boost version
  8. dll.a – stub library to link to use the dynamic library

Continue reading Scons Build System

A Tour of C++ / Bjarne Stroustrup

A Tour of C++

My earlier review (written a day ago) was not fair. Thinking about what I wrote, my prior familiarity with a number of features introduced in C++11 caused me to incorrectly state that the features were not covered in sufficient detail. So, I’m revising my recommendation that this book is sufficient to get you started writing modern C++ code that uses most of the significant new features of C++11 and with appropriate pointers to corresponding chapters in Stroustrup’s tome (which I consider an excellent reference) for in-depth study.

Verdict: Highly Recommended

[Older, Less Fair Review for Posterity]

It’s a decent read to brush up on C++, if you’re a bit rusty. I was looking for something that would cover the newer C++11 features in greater detail without having to wade through his larger tome. But I’m a bit disappointed that this rehashed some fundamentals, rather than dealing with the new language features in greater detail. It’s not a bad read for the 6 hours I spent on its 14 chapters, but it’s insufficient and I’m still on the lookout for one that mainly covers C++11.

Weekly Planning


With my annual goals in mind, I then make a priority list every Sunday night of what I plan to accomplish in the next week. That priority list will include both immediate assignments and steps toward my annual goals … I tightly schedule Monday and loosely schedule the rest of the week. Then on Monday night I schedule Tuesday more tightly, based on what’s left on the priority list and what’s come up on Monday. Tuesday night I schedule Wednesday, and so forth. I’ve usually gotten most things done by Friday, which can be a mop up day or a time for more planning.

– Laura Vanderkam
What the Most Successful People Do at Work