Re: [boost] Status of the CMake-ification

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