Take the 2-minute tour ×

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.

share|improve this question
Take a look at the answers to this related question: stackoverflow.com/questions/389496/… –  KeithB May 17 '10 at 11:41
Fixed links from @HughieColes' comment: gamesfromwithin.com/the-quest-for-the-perfect-build-system & gamesfromwithin.com/… –  MatthewD Feb 22 at 3:45
You could take a look at Ant cpptasks. –  snowandotherjoys Jul 8 at 5:38
add comment

8 Answers

up vote 6 down vote accepted

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.

share|improve this answer
SCons sounds really interesting for me and there seems to be good IDE integration as well: scons.org/wiki/IDEIntegration Any downsides? –  flo May 18 '10 at 8:20
Sorry for the double post, but here is a nice comparison with almost all other tools: scons.org/wiki/SconsVsOtherBuildTools –  flo May 18 '10 at 8:34
As mentionned, properly configured Makefiles are faster, it's just they are less readable. At work we are currently going toward a custom solution (that I can't share) which involves Makefile generation and we will only use SCons for custom pre-build / post-build steps which don't fit in there. But then we have some large projects around :) For small projects you'll probably not notice the speed difference. –  Matthieu M. May 18 '10 at 9:41
Interesting, I read somewhere that SCons is slow. On the other hand, in my opinion, if the build script is the bottle neck during the build, you should seriously get a faster build machine :D Your custom solution sounds somewhat like what CMake does - have everything in an easy-to-learn easy-to-read/write language, and generate a build script for the actual build system to do the dirty work, which doesn't have to be repeated every build. CMake also generates make files or MSBuild scripts. But then, I don't have a large project - the build takes about ten minutes on the server. –  OregonGhost May 18 '10 at 10:41
Related to SCons slowness I think it depends on the project size. For a 10m build you'll perhaps scrap off 30s. The crux of the matter is that YOU generate the targets, so if your scripts to generate them as slow, then the whole process is slow since SCons does not begin building before all the targets have been defined (it automatically decides in which order build them). However our migration has more to do with a company wide deployment of a tool rather than a choice: it's easier to depend on a supported tool than to roll your own, and the tool is pretty neat. –  Matthieu M. May 18 '10 at 12:49
show 1 more comment

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 ;)

share|improve this answer
Thanks for your elaborate and well-balanced post. CMake seems to be my #2 choice so far. –  flo May 18 '10 at 8:21
@flo: While you'll be likely fine with SCons, I'd suggest reading how and why the KDE team (with one of the largest OpenSource projects in the world) switched from autotools to SCons to CMake: lwn.net/Articles/188693 –  OregonGhost May 18 '10 at 9:37
You don't need to repeat the condition in the else and endif; it's there to help document; but is optional. –  Billy ONeal Apr 19 '12 at 2:21
add comment

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.

share|improve this answer
Thanks for the pointer, but wow, the installation mechanism is certainly novel, possibly even perverse. freehackers.org/~tnagy/wafbook/index.html#_running_waf –  msw May 18 '10 at 3:48
Upon further reading, waf appears to be intended to do something, but I'm not sure it is software building. Are 40 lines of makefile really needed to build hello_world.c? waf.googlecode.com/svn/trunk/demos/cc/wscript –  msw May 18 '10 at 4:04
add comment

I had a chance to compare all of them myself. First we've used make. It is ugly. You have to be make expert to really understand what's going on. I wouldn't take the pain ever again.

Then we moved to SCons. It's syntax is OK, you can still do ugly things because you can write your own scripts which tend to be programs. This gives you a lot of flexibility. But we kicked SCons because we had to wait for about 20 seconds for project scan and another 20 for build every time. Then my colleges wrote python code to cache it's scan results to files and almost doubled the performance. You still had to wait about 20sec for a build, when you've added a file or removed one from the project you had to rerun build with a --fill-cache parameter.

Then I've moved the project to CMake which is definitely my tool of choice. It's structure and syntax a very well readable and also documented. It generates you projects for almost every IDE and also early supports the new IDEs on the market. The build process is then as fast as your IDE and you only need to return to CMake when you add new projects or change project properties to stay with CMake

So I would suggest CMake

share|improve this answer
add comment

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".

share|improve this answer
I can't agree with make. It doesn't offer anything you can't get anywhere else, doesn't fit with modern IDEs, doesn't have many tools built-in (you'll likely have the same command-line-tool-dependency I describe in my answer, which is really bad for platform-independence), and is not really elegant, especially compared to recent build systems (or generators like CMake). It's a well-justified opinion to prefer make, so it's not a -1, but it's not +1 either (for me), simply because I can't imagine any of our projects that would have benefitted from manually using make instead of CMake. –  OregonGhost May 17 '10 at 10:02
It it's simple idea, that puts Make out of the competition. It fits perfectly fine at least into Eclipse & Visual Studio development model. Unlike CMake and other "build system generators" you are manipulating the behavior of the build system directly, not via features&bugs of the generator. It's also worth to say that for C++ development and three platforms you only need to specify 30 command lines (compile, link lib, link bin, static/shared, debug/opt) x (Linux, Win, MAC), which is exactly 30 lines of code, and you don't have the overhead of using 5% of the "generic build system". –  bobah May 17 '10 at 14:27
Now add fetching, unpacking and configuring all build prerequisites and fully deploy the build and I'll bet 30 lines won't be enough, especially for different environments. One of our CMake projects calls 50+ CLI commands, of which none is for basic stuff like compiling. I also can't agree with make fitting into the Visual Studio development model - you have to maintain the makefile(s) and the solution side-by-side, while with CMake, you have only one source for both. In my opinion, the time for command-line based build scripts is over. "Direct control" also means "more work to do". –  OregonGhost May 17 '10 at 16:12
@OregonGhost: good points, though I can complain with the same arguments, once you script deployment yourself you know at once what it does and it does exactly what you need. But otherwise, I think the author of the question has got a good idea now about goods and bads of Makefile and CMake based approaches to build process design. –  bobah May 17 '10 at 17:01
add comment

Also an other tool is TUP. My experiences are pretty good with this tool. Tup

  • Handles dependencies automatically (no need to call gcc -M).
  • Works with partial dependency graphs, therefore it is very fast.
  • It supports recursive directory structures, in a brilliant way (Tuprules.tup)
  • Supports git in an outstanding manner: Can create the .gitignore files automatically, based on the target list.
  • Extremely easy to use and the syntax for the Tupfiles are very simple.
  • It maintains a consistent build of the source files, even when you renamed a file, or deleted one. Therefore the built binaries are always reflecting the current state of the source. It also means, you never ever need to clean your project.

After using it for two quite complex projects I can say only a one bad thing about that:

  • It is complicated to use together with ClearCase dynamic views.
share|improve this answer
add comment

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.

share|improve this answer
add comment

I have tried:

  1. scons <--- Too slow.
  2. waf <--- Pretty good, but overengineered in my opinion. Sometimes not easy to guess what to do.
  3. cmake <--- Not nice syntax, but pretty robust and quite fast.
  4. autotools (mythbuster docs) <--- Only unix. Best handling cross-compilation.
  5. tup <-- It is so fast and correct that it is unbelievable.

You are looking for industrial strength. I would say that scons is out, because it is too slow IMHO, even if it was nice. It does not have a config phase either.

waf looks good, but I found fighting how to do a few things, specially nested projects, in the correct way.

autotools is REALLY robust, though it is out if you want to support windows. Cross compilation is really robust in autotools.

CMake: I think you should go for this one. It is quite fast, it handles configuration just as autotools but works in windows, it generates projects for xcode, visual studio, make and more. This is a nice feature if you have a multi-platform project since you can generate the projects for the IDEs of choice. But I must say that I don't like the syntax too much. Anyway, it handles big projects well. I would go for cmake if I wanted an "industrial strength" solution. Even if I personally hate it a bit, it is the only viable option.

Tup: I think it is more unix-oriented. But I must say that for me it is the nicest one and it is insanely fast and simple. I love it. But what you need is cmake.

share|improve this answer
add comment

Your Answer


