From a personal point of view, Boost.Build (even if not perfect as it is) does what a build system should do: abstract the user all the detail on how the objects will be built and let him only care about
Hi, My 2 cents regarding build systems as I've recently had to write a build framework using CMake and as I use Boost.Build for personal projects. I think Boost.Build and CMake are at a totally different level of abstraction: CMake is low-level when Boost.Build is high-level. For comparison with other build systems, Make, SCons are at the same level as CMake. Premake is probably closer to Boost.Build (I don't know enough others but there's not a lot being as high-level as BBv2). Of course SCons and CMake still have a major advantage over Make because of their portability. But they offer a very little abstraction over simple Make. Surely, there are some built-in rules to easily create shared/static libraries or executables, but you still have to define a lot of things manually. As an example, I quickly realized that CMake is simply unable to create both shared and static version of a library if you don't explicitly write the two rules to build them. For comparison, with Boost.Build, creating a library is as simple as writing: lib foo : bar.c ; Then, depending in which context the library is used, BBv2 will create shared or static or both versions of the library. You don't have to care about the details, you'll have automatic resolution of what is required to satisfy the build request, based on the build condition you asked for. The abstraction level of Boost.Build is also very visible when you start working on multiple compiler and/or multiple build variants. As long as you don't need fancy compiler flags (and I think most projects shouldn't play with fancy compiler flags) you can trust Boost.Build to abstract all the details of the compiler flags and to offer you the possibility to build everything you want, at once. With CMake and others, as comparison, you are only able to build one variant at a time, and by default everything will be build in conflicting way between build variants (build once in release mode and once in debug mode, and you'll overwrite the previous build output). As said, you can use different build folders for different variants, but that's much less easy to use and not very maintainable unless you maintain a wrapper around the build system that does this for you. I like very much Boost.Build, and I was quite disappointed to hear that there's a plan to move Boost to CMake. Boost is the main user of Boost.Build and I'm a little bit afraid of seeing it disappear, or being less and less unsupported. Even if I perfectly understand the reason of this change: Boost.Build suffers from lack of documentation and lack of popularity, whereas CMake is very well documented and widely used, it leaves me a bitter taste in mouth. the high-level objects and their relations. CMake and others are "old-generation" build systems, which may be used as building blocks to achieve this goal. -- Beren Minor