Previously, I’d put up a post describing the component object model of our Scons based build system at Axham Games. If you haven’t already read that post, you might want to take a gander; it would ease understanding of what is discussed here. Somewhere along the way, as tends to happen with a lot of software systems, our build scripts began showing signs of atrophy.
Note: This post is written with a view to help myself and others running development teams. This post goes into details about poorly done software development work, but the goal is not to cast blame, but to learn how to spot the signs early and make appropriate course corrections before reaching a point where a system needs to be completely re-written.
Note 2: This post was originally written in Jan 2015, but was put on the back burner because I got injured in an accident. I didn’t find time till now to wrap it up and publish it.
In our system we treat sets of libraries as a single component and a Python class represents a component. E.g. all the boost libraries have common parameters and are group together as a single component. Each project can choose which libraries within the set to use by specifying them in the SConstruct file and overriding them within per project SConscript files.
Here’s an example of the configuration used to link to Lua libraries. Continue reading Software Atrophy: An Example
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
Continue reading Scons Build System
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.