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