In article
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