Re: [boost] boost development process / scope

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