Re: Using Boost as a Library Dependency

From: Rene Rivera (yg-boost-users_at_[hidden])
Date: 2003-08-11 16:23:40

In article <bh83bf$994$1_at_[hidden]>,
 Jason Winnebeck <yg-boost-users_at_[hidden]> wrote:

> I recently decided to refactor my library's API using the benefits given 
> by boost::shared_ptr, so this now means my library uses boost.  I'm 
> trying to figure out how my installation process should go.
> 
> Since I'm only using shared_ptr I've trimmed down a custom boost version 
> that is only a few hundred k (rather than 10 megs) of just the files 
> that I use.  I've put the minimum boost files in my own directory 
> structure so that my library can compile on its own. 

That's a reasonable thing to do.

> But when using the 
> library, then what would the user do?
> 
> Ideally I could have the installer for my library by copy the files to 
> the compiler's include directory, but that's not particularly nice, 
> espically since Boost is quite a popular library, and I don't want to 
> litter up their include directory and most espically not overwrite any 
> installation of Boost they have placed there.

Putting things in the compile directories, any of them, is a really bad thing 
to do.

> One thing that might work, if compilers support include directory 
> "overrides" is if the user is using the full Boost library, to place its 
> -I line before (or after?) the -I for my library, so that they can see 
> my includes, but any boost includes will be "overridden" by their full 
> version of Boost.

If you order them to be: user paths, then you library paths most compilers 
will search in that order and therefore you would get the override effect you 
want. CodeWarrior is the one exception I know about since it caches files it 
doesn't always override includes.

> But this leads to another question:  If I compile my library with Boost 
> x but the user has Boost y installed when he links with my library (I DO 
> pass shared_ptr back and forth between user code, so it's not just used 
> internally), what will happen?  The shared_ptr interface seems to be oft 
> changing, and so right now my code would only compile for Boost 1.30 (or 
> later?  

Now that's the rub... Because of ABI incompatabilities you have to be 
exteremely carefull if you want to allow users to use a different Boost 
version than the one you provide. My suggestion is don't allow it... Unless 
you are providing source code to your library.

The least problematic solution is to include your mini-Boost right in the same 
include directory that you are prociding for you library. You then only need 
to ask users to add your include to their configuration.

>Speaking of that, anyone know why there are no files listed for 
> download for Boost 1.30.1 but it was announced a week ago?).

Because of a misunderstanding in the making of the distribution there where 
serious problems with it. So Dave removed the files to prevent further 
questions about that release. He's working on a 1.30.2 release to remedy the 
situation.

> I'm new to these things so I appreciate any feedback or answers you 
> have.  The library is just an open-source library I'm writing on my own 
> free time, and I don't have a lot of experience from using/installing 
> commercial C++ libraries to draw upon.

Ah, that answers the source question ;-)

So you might be better off just telling users that they need to have some 
minimum Boost version and leave it at that. Most developers are smart enough 
to go get the Boost source and configure their compiler to know about it, on 
their own.

HTH.

-- 
-- grafik
-- Don't Assume Anything