In order to satisfy various users request and to limit potential whining about implicit dependencies on boost, I've started lookign at how to embed boost components into my own tools. What are the usual way to do that ? I pondered working with a given version (say 1.42) in which I could add w/e patches and fixed from the trunk along with my own custom patches. I then use BCP to extract sub boost compoennt to my release package. Now, the final funny thing is that, for various reason, we don't use bjam atm for our own product build. I guess adding a makefile fuel like dependency: bjam --with-xxxx is enough for example ? Any experience to be shared on that topic ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Mon, Jan 25, 2010 at 8:54 AM, joel falcou <joel.falcou@lri.fr> wrote:
In order to satisfy various users request and to limit potential whining about implicit dependencies on boost, I've started lookign at how to embed boost components into my own tools.
What are the usual way to do that ? I pondered working with a given version (say 1.42) in which I could add w/e patches and fixed from the trunk along with my own custom patches. I then use BCP to extract sub boost compoennt to my release package.
Now, the final funny thing is that, for various reason, we don't use bjam atm for our own product build. I guess adding a makefile fuel like dependency: bjam --with-xxxx is enough for example ?
Any experience to be shared on that topic ?
If you are including Boost in BCP anyway, then: If the libraries you are using are header-only, you do not need to build anything from boost at all, just have your own code include it. If there are libraries that are not header only, I have found it is just about as easy to add the cpp files for those in my own project as well (unless you need a shared library, but that is easy enough as well).
OvermindDL1 wrote:
If there are libraries that are not header only, I have found it is just about as easy to add the cpp files for those in my own project as well (unless you need a shared library, but that is easy enough as well).
I'm amazed I never even considered this. Thanks for the tip. Cheers, Brad
you might want to take a look at the directory in boost/libs/serialization/vcide. This contains all the library build and test for the serialization library. It doesn't conflict with boost bjam build in anyway. It's just easier to use IF you're using VC IDE anyway. I use a similar method for all my project. Brad Hubbard wrote:
OvermindDL1 wrote:
If there are libraries that are not header only, I have found it is just about as easy to add the cpp files for those in my own project as well (unless you need a shared library, but that is easy enough as well).
I'm amazed I never even considered this.
Thanks for the tip.
Cheers, Brad
On Mon, Jan 25, 2010 at 9:50 PM, Brad Hubbard <boost@brand-hubs.com> wrote:
OvermindDL1 wrote:
If there are libraries that are not header only, I have found it is just about as easy to add the cpp files for those in my own project as well (unless you need a shared library, but that is easy enough as well).
I'm amazed I never even considered this.
Thanks for the tip.
No problem, but fair warning, it works with most things, but not everything. For example, Boost.Python you want as a standalone library if you are making modules that will be linked by the python main exe, however if you are embedding python in your own executable, then it is fine to just drop the cpp files into your own app then, things like that. Generally, as long as you are not using boost libraries in some linked in DLL's, there are no problems, if no external non-boost but boost-using dll exists though, then it is situation dependent on whether it is safe, some situations as described between whether you want to use dynamic or static anyway.
On Tue, Jan 26, 2010 at 6:37 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
No problem, but fair warning, it works with most things, but not everything.
For example, Boost.Python you want as a standalone library if you are making modules that will be linked by the python main exe, however if you are embedding python in your own executable, then it is fine to just drop the cpp files into your own app then, things like that.
Generally, as long as you are not using boost libraries in some linked in DLL's, there are no problems, if no external non-boost but boost-using dll exists though, then it is situation dependent on whether it is safe, some situations as described between whether you want to use dynamic or static anyway.
I use this method also for DLLs, and it works fine for me. The only problematic part is identifying which preprocessor directives you need to pass for each compiled library you want to include - e.g., -DBOOST_PYTHON_SOURCE, -DBOOST_THREAD_BUILD_DLL -DBOOST_SERIALIZATION_DYN_LINK=1 and the like. Cheers, Francesco.
As a follow up, I ended up extracting part of boost trunk as svn:externals into a local subdir of our own VMS. As all of these are headers only, it worked without additional hassle.
participants (6)
-
Brad Hubbard -
Francesco Biscani -
joel falcou -
Joel Falcou
-
OvermindDL1 -
Robert Ramey