configuring a library to work with multiple versions of boost

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. Thanks. Ross Boylan

Ross Boylan
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? -- Dave Abrahams Boost Consulting www.boost-consulting.com

On Tue, 2005-11-01 at 06:01 -0500, David Abrahams wrote:
Ross Boylan
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.
participants (2)
-
David Abrahams
-
Ross Boylan