Re: [Boost-users] configuring a library to work with multiple versions of boost

From: Ross Boylan (ross_at_[hidden])
Date: 2005-11-01 17:08:10

On Tue, 2005-11-01 at 06:01 -0500, David Abrahams wrote:
> Ross Boylan <ross_at_[hidden]> writes:
> 
> > I have a library that uses boost and also uses a pre-release version
> > of the ptr_container (header only) library that eventually made it
> > into boost 1.33 (I think).  I would like people to be able to compile
> > my code with various versions of boost.  I've had it working with 1.31
> > and 1.32, and expect to have it working with 1.33 when that reaches my
> > distribution.
> >
> > I have a subdirectory with the pre-release ptr_container library and
> > some supporting code from elsewhere in boost.  This is in a "boost"
> > subdirectory of my project, which has included the directory above
> > that unconditionally in my compilations.  With 1.33 I think I want to
> > ignore my local stuff completely.
> >
> > I'm using autoconf and libtool.  Are there autoconf macros available
> > for detecting the boost libraries?
> >
> > Do people have any suggestions about the best way to proceed?  One
> > possibility that occurs to me is to test for the version of the
> > library at configure time, and make the include path depend on the
> > results.
> 
> I can't help you on the autoconf front, but see the thread at
> http://lists.boost.org/Archives/boost/2005/09/93902.php (read the
> followup messages).  Bjørn Roald was working on a modification to the
> bcp tool that would handle the other issues.  I'm not sure how far
> along he got with that project, but I'd _really_ like to see it
> completed.  Maybe you and he can work together?
> 
I think that thread addresses a problem which is trickier and different
than mine.  It is trickier because I think I can assume that my code is
only user of boost in my system.  It is different because, as I
understand it, the goal to have bcp produced a subset of the library
that uses a different namespace.  The boost code fragments I have are
not free standing (I think), so if they end up looking for stuff in
my_boost:: they will not find stuff in the base library, and won't work.

I recall some tricky interference issues between the boost code
fragments I use and the main boost library with some versions of both.
Unfortunately, I can't recall the details. So I may be getting into a
can of worms, and should just require 1.33 and eliminate the local code.