Boost logo

Boost :

Subject: Re: [boost] Status of the CMake-ification
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-11-17 11:06:37

On 11/17/15 12:47 AM, Domagoj Saric wrote:
> On 17.11.2015. 6:01, Robert Ramey wrote:
>> There's no reason you can't do it for your own library.
> <...>
>> On the other hand, boost build does somethings that CMake can't do.
> Such as (an honest question)?

A fair question.

I spent a fair amount of time figuring out CMake in the course of
working on a non-boost project. I decided to capture my thoughts and
experience on a page in the Boost Library Incubator which summarized my
experiments with alternative build systems. I found all the build
systems lacking in some way. I don't think I'm alone as this page is
the single most popular page in the whole incubator. So I would suggest
that people can look at that for a complete view. But here are some
things that immediatlly come to mind.

a) Bjam has a steep learning curve. CMake seems easier and it is - but
it's still too complicated.

b) Bjam permits one to have one build file refer to another. CMake
might permit this, but it's sufficiently unobvious that I couldn't
figure it out. This is useful for us. For example if I want to build
(and run) tests for the serialization library, it will automatically
build the libraries it requires and nothing more - just by invoking the
build script from within the test directory. CMake might be able to do
this - but it's very non-obvious how one would do this.

c) CMake couples all your directories together by sprinkling
CMakeList.txt files throughout one's directory structure. This is very
intrusive and inconvenient as far as I'm concerned. Bjam is better in
this regard.

d) CMake "language" is simpler than BJam "language". There both very
inconvenient to use and understand. But the "language"s, clunky though
they are are good enough for the task. The real problem is that building
applications these days is very, very, very complicated. It's evolved
over many years as applications have gotten more and more elaborate.
Basically, it's a hard problem and the difficulty of making tools to
help reflect that.

e) CMake builds the "build script" which Bjam builds the app. This
means that CMake can build my IDE for the project and BJam can't. I use
Apple XCode for an IDE. Previously I used MSVC IDE to maintain the
serialization library. In both cases, maintaining these IDE by hand was
difficult and time consuming (MSVC) and pretty much impossible (XCode).
This one feature has made CMake indispensible to me.

f) CMake can't run a compile only test - or even more difficult - a
compile test which has to fail - without some CMake gymnastics. At 67 I
don't go in for gymnastics so much any more. Bjam handles this easily.

I'm sure I could mention other stuff if I thought about it more. But my
conclusion is - if you're doing a project which is not boost - use
CMake. If you're doing a boost project - do both.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at