installing boost libs for dependant apps
I just completed porting our server from XP to Linux, which uses Boost::Thread for the threading library. I found it was infinitely more convenient to publish the libs in their various formats (variant|sub-variant) into a common, top-level folder under BOOST_ROOT. This made it much more managable to both link it into my application (without having to grist the folder name) and add the proper path to my LD_LIBRARY_PATH env var so it could find the shared libraries when I ran. I don't know if there is a prescribed way of doing this already in place, but I did not see anything in the build documentation (like bjam "Install [folder]" or some such). I ended up modifying the BOOST_ROOT/Jamfile to have a stage target that published all the threading libs to BOOST_ROOT/bin with proper suffixes for the variants I cared about (debug and release for the moment). I still had to append the proper suffixes in my own Jamfile (I used BJam for my make as well), but it was a heck of a lot better than a 10 deep folder hierarchy. I have a couple of question and two requests. For reference I am using a cut from CVS around 2/6/2003. How are others doing this sort of thing that are using Boost? Is there a common way to do what I did by doctoring the Jamfile that is less invasive (so I don't have to repeat in the future when I get releases from CVS)? I am new to Linux & Boost, so may not know how I should be getting at these things. My request, if the answers to the above don't address them, is that some form of install or publish to a common location be added to the boost build. If I were more intimately familiar with Boost and the build system (and the various installation platforms) I would volunteer to help, but... My second request may also already be possible, but my limited experiment and reading made it seem not. I'd like to be able to declare a sub-project that points to a whole other boost-build.jam hierarchy; e.g. I want to make Boost a sub-project of mine. This seems much more plausible and likely in the new versoin 2 format where the dependency declarations are more straight-forward (by name, not explicit path). I await your feedback. Thanks. michael
participants (1)
-
Michael Hunley