Boost logo

Boost :

Subject: [boost] CMake - one more time
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-20 11:49:12

Inspired by the recent discussion regarding CMake, I've spend some more
time looking at this. As a result, I've done the following.

a) I experimented with using CMake in the more customary manner in my
canonical project Safe Numerics - (see Boost Library Incubator). The
current version does distribute CMakeLists.txt around the subdirectories
of the library root. My original objections to doing this were assuaged
when I realized that boost build does the same thing. That is I
typically have Jamfiles in side of test, example and sometimes other

b) One of the features that I much like about Boost Build is the
possibility of arbitrary nesting of Jamfiles. This permits one to
build/test a portion of one's library (e.g. test, example) as well as
the whole library. For a large library this is indispensable. In spite
of what many people think, this is not easily supported with CMake.
However, I have found that with some extra effort, it is possible to
support this to the extent we need it. So in this project ONE CAN BUILD
(actually create an IDE project or makefile that builds) ANY OF THE

c) CMake is indispensable to me:

* it creates IDE projects for "any?" platform. I use IDE alot.
* everyone else uses it - so it makes it easier to promote my work to
* it's easier to make work - still a pain though
* There is lots of information, around the net about how to use CMake,
how easy it is etc. Although they help when you're looking for an
answer (which is all the time) - they really betray how complex,
arbitrary and complex the system is.
* It has an almost of idiot proof GUI version which I use a lot. I
really like this.
* CMake is well maintained and supported by it's promoters.

d) Boost Build
* either just works (great!) or doesn't. If it doesn't it's almost
impossible fix without getting help
* I've never run across anyone outside of boost who uses it. It makes
it harder to promote my work.
* It's natural to compose projects into "super projects"
* it's almost impossible to integrate with and IDE. At one time, I had
things setup so I could debug executables created with boost build with
the Visual Studio IDE and debugger. But it was just too fragile and
time consuming to keep everything in sync.
* it has a lot of "automatic" behavior which can be really, really
confusion. A small example: you've got multiple compilers on your
system. When it discovers this, it just picks the "best" one and you
don't know which one you got until the project builds (or not). I'm
sure this was implemented this way to make usage of boost build "simple"
but it has the opposite effect. Much better would be fail immediately
with a message "multiple compilers found:... use toolset=<compiler name>
to select desired one."

Some Conclusions - I'm trying to not make this a rant

a) The ideal, platform independent build system does not yet exist. I
guessing it never will. I'm sure it won't happen in my life time - but
then I'm 68 - maybe you'll get lucky.

b) Both systems are much more fragile, complicated and opaque than their
promoters try to make you believe. It's not that they're lying, they
truely believe in their own stuff. There is much re-invention of the
wheel - The each created their own (half-assed) little language for
goodness sake!!!

c) Neither has really resolved the issue of nested projects in a clear
way. Boost Build probably does or can do this. CMake has a system of
"packages" and a whole 'nuther layer about "finding" them. Assuming it
can be made to work - given the amount of time I've invested in CMake, I
should know how to do this by now.

d) I think it's time for Boost to be a little more open about
tolerating/encouraging alternative build systems. I think our
documentation approach is a model. Yeah it's a hodgepodge. But the
various ways of doing pretty much work and generally don't stop working
and we don't have to constantly spend effort bringing things up to the
latest greatest system (which we couldn't agree upon anyway). We have
libraries which have been going strong 15 years - and people can still
read the docs.

e) We should find some way to recognize those who have made the system
work as well it has. Doug Gregor (boost book), Eric Niebler, Joel
Guzman (quickbook). Vladimir Prus, Rene Rivera, Steve Watanabe. I know
there others but these come to mind immediately.

Note that I have only addressed the issue of library development which
is my main interest. I'm really not seeing this issues related to users
of libraries. In particular, CMake has the whole "find" thing which I'm
still not even seeing the need for. If I want to use a library, I can
build the library and move it to a common place with the headers,
specify the include directory and I'm on my way. I'm sure someone will
step up to enlighten me on this.

Robert Ramey

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