From the boost build / merge

...

The same goes for boost documentation which I would really like to use. But I don't feel confident that "it just works"

Heh, there's nobody here who would disagree with that.

To me the sad part of this is a) that I personally have a HUGE need for something like the boost documentation system in my own projects. b) I feel that if it were subjected to the normal boost testing regimen, it would be a dependable product by now. Or at least we would have a good test matrix which I could use to know what aspects I can't use in my environment. What I would like to see is: a) a directory structures that looks like one of the following .../libs serialization doc *.html // i.e. same as we have now or .../libs serialization doc Jamfile.v2 (optional) pdf (optional - built on demand by bjam from boost book) *. pdf files windows html help (optional - built on demand by bjam from boost book *.chm files html (included in distribution - optionally (re-built) by bjam from boost book) *.html files boostbook (hand prepared - or built by bjam from quickbooks) * .. boost book filles quickbooks (optional - hand prepared) For any library I was interested in I could review the html or build the version I needed by going to the doc directory and invoking something like bjam -???? or bjam -????? pdf And if I want to spend $300 on a proprietary package, I could do that as well - just as I do for my compiler. But to do this the following tools have to be tested on a regular basis like the libraries are: a) boostbook -> pdf b) boostbook->windows html help c) boostbook->html d) quickbooks->boostbook so there would be a couple of "new" tool/library directories ../tools boostbook build Jamfile.v2 doc boost book documentation src ... test quickbooks ... same as above And of course these tests would be part of the normal test matrix. I realize that this sounds like a lot of effort. But then a lot of the above is already in boost somewhere so a large part of the effort would be shuffling a round stuff that's already in there (boost). I believe that reorganizing boost documentation along the above would result in a robust and very popular tool/library. Robert Ramey