Re: [boost] Release Tools Analysis Part I: Build systems

From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-08-06 09:32:49

On Aug 4, 2007, at 5:42 PM, David Abrahams wrote:
> 3. Platform/compiler-independent build specification.  This one seems
>    pretty important on the face of it.  If library authors' tests
>    won't run on platforms to which they don't have direct access,
>    we'll need to find people to port and maintain test specifications
>    for the other platforms.
>
>    On the other hand, very few tests are doing anything fancy when it
>    comes to build configuration.  To understand the real impact of
>    this BBv2 feature, someone would have to objectively analyze the
>    cmake build specifications Doug and Troy have been working on for
>    complexity and portability.  If either of those guys can be
>    objective, it would be fastest if they'd do the analysis.

It's well short of an analysis, but I can give you my experiences  
with this. The CMake and BBv2 descriptions for building and testing  
libraries have nearly a 1-1 correspondence. Troy and I built a thin  
BBv2-like layer over CMake that gives it the kind of platform/ 
compiler-independent build specifications we're used to in Boost.  
See, e.g.,

        http://svn.boost.org/trac/boost/wiki/CMakeAddLibrary

BBv2 is far more concise when one needs to do complicated things,  
e.g., add a specific flag when compiling a certain source file for a  
shared library on compiler X. The same is possible with CMake, but it  
requires an "if" statement or two. In Boost's build files, this kind  
of thing didn't come up more than a handful of times, and it was  
always the same pattern.

> 4. Cmake's built-in programming language is even more horrible, IMO,
>    than bjam's.

CMake's language is certainly more ugly.

> I bet you get used to it, like anything else, but it
>    does present a barrier to entry.  On the other hand, it's my
>    impression that most programming jobs can be done more simply and
>    directly under Cmake because it lacks BBv2's
>    multiple-toolset/variant builds, and so has no need for virtual
>    targets.

I find CMake easier to work with, but the reason you give is not one  
of my reasons. It actually comes down to two things, for me.
        (1) Reference documentation: All of CMake's macros are documented in  
one place, with a terse-but-sufficient style that works well for me.  
I find it very, very easy to zero in on the macro I want to get the  
job done.

        (2) Error messages: this is particularly amusing coming from a C++  
template meta-programmer, but BBv2's error messages kill me. Just  
like with template metaprogramming, BBv2 is bending the Jam language  
to something it wasn't meant to do, and when something goes wrong,  
you get an eyeful of backtraces that I find hard to decipher. CMake  
gives much more concise, more direct error messages, which has made  
it far easier for me to work with (even though I've spent less time,  
overall, with CMake than with BBv2).

I was hoping not to have the big CMake discussion now, because,  
frankly, all of my Boost time (and more) is going into the Subversion  
repository and Trac. I just can't dedicate enough time to this  
discussion to represent CMake well.

        - Doug