Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-05-04 13:50:12

> If I had nothing but free time, I'd investigate using CMake instead
> of,
> or in addition to, Boost.Build. From the website:
>> CMake generates native makefiles and workspaces that can be used
>> in the compiler environment of your choice. CMake is quite
>> sophisticated: it is possible to support complex environments
>> requiring system configuration, pre-processor generation, code
>> generation, and template instantiation.
> With CMake, we could deliver makefiles and vc project files, so people
> can use their own build environments instead of having to learn
> ours. I
> think this would remove a barrier to Boost's adoption. This article
> describes the experience of the KDE team switching to CMake:

This would be great. A significant number of OSS projects already use
CMake (in addition to kde : ITK/VTK, in particular, are close to my
heart). It also supports XCode projects, which would simplify the
generation of Boost frameworks for OSX developers...

> FWIW, quickbook is merely a front end for existing external tools
> (docbook, doxygen, fop). Nobody actually has to use quickbook -- they
> could program directly to these lower level tools, and BBv2 supports
> that. But the flakiness of these tools, and the length of the
> toolchain,
> has been a constant source of trouble for us.

Fortunately, there is no mandate on the specific format of
documentation for Boost libraries. However, I agree that it is
desirable to have some level of consistency of documentation format.
I know that Steven spent a significant amount of time getting
quickbook to work for the Boost.Units documentation, so I would agree
that flakiness is a problem. Given that writing documentation is
generally the least favorite activity in any given software project,
adding even small hurdles is clearly undesirable...


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