Jason Winnebeck 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. 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.
If your installation has an include directory, the user normally must add that directory to the compiler's include path in order to use your library. Because of that, the best solution is to put whatever you have distributed of Boost beneath your installation's include directory using the exact same structure Boost already has. Now your end user, in order to use your distributed Boost functionality, merely uses normal Boost include notation, ie. #include <boost\someheader.h> and the Boost header file will be automatically picked up. Your only problem is if you distribute your particular subset of Boost with your product and your end user is also using another release of Boost within their product. Then they must take care to partition the functionality which you provide with Boost in separate source files from the functionality which the rest of their modules use with a different version of Boost. This shouldn't be too hard for source files, since it is normally very easy to divide class member function definitions in separate source files. If, however, on the rare occasion one of their header files must include both one of the Boost headers you supply and a Boost header from another distribution, then it becomes problematical using the normal Boost include notation from within the same header file. But this latter is indeed a rare case in practice, and I wouldn't worry about it too much unless it actually occurs.