Re: [boost] [ot] choosing a build system

Subject: Re: [boost] [ot] choosing a build system
From: Beren Minor (beren.minor+boost_at_[hidden])
Date: 2012-05-10 04:52:40

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.

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