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

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-09-23 09:18:42

John Maddock said:
> Bjørn,
>
> A very interesting read, thankyou for raising this.

thank you.

>
>> - commercial support for our use of Boost
>
> Just out of interest what kind of support would be most beneficial to
> commercial users?

Hard to answer in a few words, but my personal feeling is that this is
much less of a concern for developers than it is for managers.  Many
managers find it hard to trust something when they have nobody they can
hit if things are not working out as expected.  Personally I have
experienced strong skepticism for ACE/TAO go away when a legal entity
stated that they sell and support the tools commercially.  You can also
then assess this company and its solidity, which is a game they know how
to play.

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

I will keep that in mind, I know you are doing a lot and that is highly
valued.  Also if I may ad, your approaches to testing has been a good
source of inspiration and solutions to me and my co-workers.  The
challenge may not be as much to do better, as there always is room for,
but maybe to make potential users better aware of what is done.

>
>> - stability of Boost API
>
> That one is tricky, Boost is meant to be at least a little experimental.
>

I know -- in a post some time back I mentioned that a sort of index of how
stable the maintainer and boost developers considered the various accepted
library APIs to be might be helpfull.  I would have an easier time getting
accept for using a library considered more stable by the developers.  This
information is not available to me now.

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

This is closely linked with commercial support.  If a product is
commercially supported by somebody I trust, then I might not care. But if
it is not, I will have to consider the possibility of having to fix
problems myself.  If I have no reasonable way of understanding the code,
it spells TROUBLE.

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

This would give one source, better than mingling with source code. 
However I am not aware if a macro is a good solution for this, does that
work well for STLport?

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

agree that there are issues with a search and replace strategy, however it
may be feasible.

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

I do not understand exactly what you mean with "proceed via macros". 
Could you point me at an example please?

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

maybe even test a library's integration in in the "std" namespace, there
will be some name conflict issues with the various standard libraries, but
it feels like a tempting thing to try.  Try the feel of your proposed
library in the std namespace...   demonstrate integration with std library
implementations -- who knows.

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

Yes,  I think I would just use "mylib_boost" since the version would be
implicit through my configuration management.  Hopefully my customers are
only using one version of MyLib ;-) .   But thats really their problem,
not mine.

Nesting would however be nice since we internally could write

#using namespace MyLib;

and then write boost code as everybody else.

--
Bjørn