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