tup [1], redo [2] and ninja [3] are probably the build systems with the most potential.
redo is the simplest, which is unsurprising given that it was originally proposed by djb. Alternatively, you could look into mk, which is the make replacement used by Plan 9, Inferno and derivatives.
I've used redo for a while but I didn't like the sprawl of shell script files for the build to work.
I switched to ninja mostly for more complex projects and it's very nice, you can do anything in the generation stage and get all the power you need and then run it through ninja and get the full speed benefit of native code for the most common operation (build it!).
I used in the past both scons and waf and they are in a way like ninja but since the actual build process is still in python the time to build is longer. scons was a big pain in the ass for a large project and I regretted introducing it. waf was ok though.
I still do use make and makefiles for simple projects. It is usually simplest to get running and requires only a build stage without any configuration like ninja does. I also have the basic constructs hard-wired into my brain and can write that simple makefile faster than I can find the example code for ninja.
There are really only three sane choices for C/C++ build systems right now, in my opinion:
1. Traditional Make files. Keep it simple, don't feel compelled to use all the dark corners of the language, and accept that it will be a little more verbose than some other solutions. And don't expect portability to Windows, since you won't get it (cygwin doesn't count as Windows). There are some portability problems between UNIX variants, but actually I think it's pretty easy to deal with these in plain old Make.
2. CMake. It makes the simple things simple and the hard things possible. It has its own simple scripting language which build files are written in, so you don't need to tear out your hair worrying about whether the the user's version of bash / python / perl / whatever matches yours. The language has the abstractions and functions that you need built-in, so most CMakeLists.txt tend to look the same (less wheel reinvention than you would get just using a general purpose language like Python or Perl for Makefiles.)
CMake is built with backwards compatibility in mind, so you can easily use old projects with newer versions of CMake. This is something you just don't get with autotools, where you have to have the correct version (not newer, not older) of autotools installed to build the project.
CMake does the detection of which header files are needed to rebuild which .c or .cc files which plain old Make doesn't do (without adding clunky extensions). CMake is also portable to Windows, which autotools is not. (again, limping along under cygwin doesn't count.) CMake can generate visual studio projects which can be used to directly build software.
3. Visual studio. If you only care about Windows, this is a sane choice.
I've gotten used to CMake and I kind of like it now. The language is atrociously ugly, but it's very functional at least and feature-rich. Ugly-but-functional is better than pretty-but-inherently-broken.
The tool has one critical function: to generate files that calculate dependencies properly.
It does not do this. Been using it since 2.6. Get one of their super-tweaky ever-changing commands wrong and it doesn't generate dependencies AT ALL on some platforms. Sure, your project builds. And it's also a poisoned dart trap for anyone who attempts to modify your code.
A quick skim of the bug list is enough to make any truly-fastidious engineer's sphincter clinch. When you have over 1000 bugs that aren't even assigned to a dev ... in a dev tool ... hoo boy.
> A quick skim of the bug list is enough to make any truly-fastidious engineer's sphincter clinch. When you have over 1000 bugs that aren't even assigned to a dev ... in a dev tool ... hoo boy.
Er, what? Chromium has over 50000 unassigned bugs. Any software that sees a lot of use is going to have lots of bugs, and depending on the workflow sometimes none of them will be assigned.
I asked you "how is it buggy?" and your answer essentially is "It's buggy, trust me."... weasel answers, much?
I'm by no means a fan of cmake. But if I use and trust it, yet can generate much better criticism than you do, how are you going to convince anyone they shouldn't be using it?
The bug list for a dev tool, that devs use, containing bugs meticulously entered by devs, carries weight. I also provided sample code above, so I clearly use the tool. And I've written and published scripts that show that it does not generate dependencies reliably.
"CMake is actually very reliable" --scrollaway
That's not criticism. That's just an opinion. No more or less valid than mine. But certainly less supported by evidence.
"Shake build systems are Haskell programs, but can be treated as a powerful version of make with slightly funny syntax. The build system requires no significant Haskell knowledge, and is designed so that most features are accessible by learning the "Shake syntax", without any appreciation of what the underlying Haskell means."
For C++, and if you don't need anything really crazy. It's very readable (JSON-like), and custom rules can be defined in Javascript instead of "learn another language". It's also very fast - kind of highlights how slow Make is! No build system should be slow.
It's usable now but still kind of a work in progress.
I always like waf. Runs a lot faster than scons and can actually handle a larger project.
It still has its own arcane syntax rather than being pythonic, which I think is its greatest shortcoming - it emulates make syntax too much, where I think it would be nicer to just be a good proper python library that specializes in build scripts.
