Piyo wrote:
> Hello,
>
> Assume that you have multiple developers developing plugins
> for a commercial package and that we recently deployed boost
> 1.34 to our facility. For some informed developers, they will
> switch over to 1.34 whereas others might not know and stick with
> 1.33.1 or even 1.32. Now imagine loading in all these plugins
> into the 3rd party app, wouldn't there be some sort of symbol
> problems especially with boost run-time libraries (take the
> regex library for example) ??
>
> Does anyone have suggestions on handling this? A typical way we
> solve versioning our open source libraries is to add a namespace
> to it. eg. SomeLibrary::v1_33_1 (although we never did attempt to
> fiddle around with boost). Any other ideas?
>
>
I did some work on this in boost a few years back. But my problem went
away as it was decided not to use boost in product libraries :-( but
only use it in applications and tools.
Basically my approach was to modify the $BOOST_ROOT/tools/bcp tool so it
would wrap boost libs in alternative namespace to "boost". I have some
code for bcp which seems to work good, but I never completed a full
regression test with all of boost. Using boost types in interfaces to
your lib/plug-in will pose some challenges with this approach.
Otherwise I think it is the way to go.
--
Bjørn
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
