From: John Maddock (john_at_[hidden])
Date: 2005-09-23 09:54:31
>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.
Good point.
>> - 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.
Understood.
>> 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?
Well I must admit I've never tried to change STLports namespace away from
the default, but the intention is clearly there. In theory it's just a
question of setting a #define somewhere and away you go.
>> 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?
Sorry, I mean things like:
#define MYHEADER <boost/whatever.hpp>
// then much later, different source file maybe:
#include MYHEADER
Boost.Config does things like that, as does MPL I believe. However thinking
about some more a global search and replace for "boost/" would probably be
good enough.
>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.
How about a namespace alias:
namespace acme_computing_boost_1_33_0 {}
namespace boost = acme_computing_boost_1_33_0;
Is that an acceptable alternative? It could be boilerplated inside the
Boost.Config system if necessary.
John.