Re: [boost] [tools][bcp] using boost internally in other libraries

From: John Maddock (john_at_[hidden])
Date: 2005-09-23 06:40:06

Bjørn,

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 
commercial users?

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

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

>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?

John.