From: John Maddock (john_at_[hidden])
Date: 2005-09-23 06:40:06
A very interesting read, thankyou for raising this.
> - commercial support for our use of Boost
Just out of interest what kind of support would be most beneficial to
> - quality assurance of Boost itself
We're working on improving our release stategy, but any ideas on how we can
do better would always be appreciated.
> - stability of Boost API
That one is tricky, Boost is meant to be at least a little experimental.
> - maintainability of Boost source code
That's a genuine concern, we have some code that can probably only be
maintained by the folks who wrote it, and that's not good at all.
>The general idea is that there are no references to symbols in the boost
>namespace between any MyLib libraries, nor in any header files in or
> >referenced from MyLib API. How can this be achieved? I have concluded
>that accessing boost trough namespace wrapping header files are
> >unpractical at best. This needs to be designed into all of boost for this
>to work, and I do not know exactly how. The main challenge is #include
> ><boost/xxxx.hpp> directives which does not refer to the wrapping headers.
I think there are two issues here:
1) Side by side binaries: requires that symbol names in binaries are unique
to the Boost version being used, or even the library being compiled.
Requires that the Boost namespace be customisable to something other than
"boost". I guess we could do what STLport does and make the namespace a
macro throughout Boost, or we could do as you suggested and do a search and
replace on "boost", unfortunately the latter is likely to be error prone at
2) Side by side headers: only needed if the library exposes it's Boost
dependency in it's public API's. Requires that the #include's get fixed up
to include via a path other than boost/. This is not as easy as it sounds,
because there are some #include's in Boost that proceed via macros.
Macro-ising this in the Boost source is probably not going to be easy or
acceptible, but I'd be interested in what other folks feel.
One benefit of placing all this inside the Boost source directly is that we
could regression test it just by running some of our tests with
BOOST_NAMESPACE (or whatever it's called) defined to something other than
>An alternative is to replace all references to boost namespace with e.g.
>MyLib::boost namespace in the boost source code and change all #include
> ><boost/xxx.hpp> directives to #include <Mylib/boost/xxx.hpp>. This would
>make a buildable library which would not share symbols with other >versions
>of boost. The result is a branch or clone if you like of Boost that can be
>used with the same effect as if we actually had a Cat1 boost >library.
>There is however serious problems here. Any management with common sense
>would say.... hey.... stop. The prospect of undertaking >maintenance of a
>branch or clone of Boost does not make much sense --- So, the only way this
>would work is to make it possible to maintain the >library in the boost
>community and somehow make the translation to the MyLib/boost namespace a
>pure production step. In configuration >management terms this means that
>the original or possibly slightly patched boost source code is under
>configuration control along with a tool-chain >used under MyLib system
>build that transforms the boost source tree to the form used internally.
>This is where I started looking at Boost >tools/bcp.
It would probably be easier (and more reliable actually) to change "boost"
to "mylib_boost_1_33_0" or whatever rather than using nested namespaces,
would that be an acceptable alternative?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk