C++ build systems

Question

I will start a new C++ project (it may have some C components as well) soon and I am looking for a modern, industrial-strength (i.e. non-beta) build system. The software will be created by several developers in 3-5 years and will run on Linux (Mac OS X and Windows might be supported later). I am looking for something that has better comprehensibility, ease-of-use and maintainability than e.g. make but is still powerful enough to handle a complex project. Open source software is preferred.

I started looking into Boost.Build, CMake, Maven and SCons so far and liked features and concepts of all of those, but I'm lacking the experience to make a decision for a large project.

Answer 1

I don't have experience with the others, but if you're looking for a cross-platform, cross-toolchain build system, use CMake. CMake is not actually a build system, it's a build script generator - it generates the actual build scripts for a lot of build systems and (and that's in my opinion the strength) generates project files for major IDEs like Visual Studio and KDevelop. Recent KDevelop versions, by the way, have Intellisense for CMake files.

The generated build scripts or Visual Studio solutions are not as elegant as they would be if created manually, but since you also don't have to maintain them manually, it's fine.

The downside of CMake is that it doesn't really come with a lot of built-in tools, or an easy way to extend it (compared to e.g. MSBuild, which is of course just a build system, not a generator). Our Linux developers tend to call Unix command line tools to do things like compression/decompression, which are not available on a typical Windows installation, while in contrast MSBuild has thousands of additional commands available from community projects, so you don't need to use the command line, and it's really easy to create a new Task for MSBuild. I'm currently looking into how to get around these limitations for CMake, because it currently means we can't entirely build on Windows, even though the code itself would build fine.

Writing the CMake files is not a beautiful experience, but it's ok. The language has some strange quirks (like having to exactly repeat an if-condition in the else and endif, which will drive you crazy especially when experimenting), and you'll really, really hate having a file called CMakeLists.txt in each and every directory which has custom build rules (and that maybe a lot, in a large project), and they all show up just with the name in your IDE ;)

Answer 2

From what you mentioned, I've tried Maven - it's too strict, doesn't scale and is designed for Java, so I'd not consider it. I've also heard from people having used "Automake", which they jokingly call "Autobreak"

IMHO, the project with long life expectation shall prefer pure Make, GNU Make, to be precise. There are several powerful features of Make, normally not used, which help avoiding boilerplate code (e.g. use of eval/call, non recursive build). It's compatible with any other build system (e.g. in our projects we successfully combine it with Ant, used for Java builds). It has an excellent documentation, and is familiar to most developers.

From my experience it is always possible to isolate makesystem from the project to the extent that most project makefiles contain 2 lines: the name of the target and "include ${MKSYS_HOME}/makesystem.mk".

Answer 3

I've used SCons for over a year now and it's really cool. It's a full build system, not a build scripts generator.

It's Python based, and you write the SConstruct and SConscript (equivalent of Makefile) in Python which allows you to call any available library you may wish for and a much clearer syntax that what a Makefile authorize.

Since Python is crossplatform, so is SCons, no problem there.

It comes bundled with a good number of targets:

• detects the binary available and automatically maps a number of extensions toward the correct binaries
• detects the correct extensions for your objects/libraries depending on the OS, though you can override it
• provides facilities for common operations (to be delayed after the build) like Move, Copy, Tar, and you can provide your own python scripts and hook them
• works out of the box and yet provides many hooks of customization at every level

It's really efficient, and even proposes advanced features (like storing a hash of the preprocessed file in a sqlite db instead of using the timestamp) even though you decide of your strategy in the end.

It also offers dependencies cycle detection for free (something that definitely does not come with Makefiles) and the interface is generally just better / automated.

Did I say it was efficient ? Well it obviously allows for multiple jobs to be executed in parallel ;)

And it's also free, like in free drink, feel free to contribute ;)

I can only recommend it.

Answer 4

Another to look at is Bakefile.

Its main strength is taking a relatively simple input file (simple as XML gets, anyway) and putting out many different native build system files: Makefile.in on autoconf-based systems (Linux, OS X command line, BSD...), Visual C++ solution and project files, Xcode projects, MinGW and generic Unix Makefiles, etc.

That said, I don't know that I would use a system like this from the start. Since the initial target is Linux and the others are "maybes", consider starting with automake, and put the Bakefile (or whatever) move off until you do your porting. It's always a mistake to build things before you actually need them. There's always a tradeoff -- the Lowest Common Denominator Syndrome in this case -- and if you don't have to pay the penalty today, put it off until you do have to pay; you may never have to pay. If you go with automake and build your files sanely, the migration won't be too painful.

Answer 5

Take a look at Waf. It's a decent system that I use for most of my projects that's written in python and derived from Scons, Make and other systems of the like.