$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Matthias Schabel (boost_at_[hidden])
Date: 2007-05-14 18:25:46
> CMake is a cross-platform makefile/project generator. Much of what
> you like about bjam and BBv2---the ability to specify platform-
> independent build rules, etc.---is also available in CMake.
I would like to cast a vote in favor of giving CMake serious  
consideration. I have used CMake to build the ITK and VTK libraries  
(as well as a few other miscellaneous projects) for several years  
now, and find it to be generally straightforward to use and tweak. My  
recent experience with BBv2 was less satisfying, although it does  
function as advertised once you tease out all the relevant details.  
As someone who uses OSX heavily, there are two features that I  
particularly appreciate about CMake : 1) it is essentially trivial to  
build Universal libraries (cross-compiled and linked into a fat  
binary) and 2) it is easy to export an XCode project file. Point 1)  
is relevant in the sense that it demonstrates the ability of CMake to  
seamlessly deal with cross-compilation and an additional post-link  
step to produce the dual-CPU binaries. While many of the developers  
in the Boost community are happy to use command line tools, in  
developing native OSX GUI applications or contributing to existing  
projects using XCode, this is suboptimal, making the ability to  
produce native project files a nice feature.
To the best of my knowledge, there is one feature that neither  
Boost.Build nor CMake supports at present on OSX, which is the  
generation of self-contained OSX Frameworks rather than standard  
static/dynamic libraries. It would be very interesting to me, for  
academic as well as purely selfish reasons, to see how difficult it  
is to accomplish this with each of these build systems, and might be  
an illuminating test of the flexibility of those systems and the  
responsiveness of the communities supporting them.
I would also like to second the points made about the Boost mission -  
while good tools are always valuable, Boost is meant to be a C++  
library project, not a tools project. It seems that offloading the  
heavy lifting of maintenance and improvement of build tools to  
another project that has this as its primary mission is a better  
division of labor; I'm also sure that any such project would be happy  
to benefit from the experience and input of Boost.Build users and  
developers.
$0.02
Matthias