[boost] CMake - one more time

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

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 
"SUBPROJECTS" (TEST, EXAMPLE) AS WELL AS THE LIBRARY "SUPERPROJECT"

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 
others.
* 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