Re: [Boost-build] third party libraries

Subject: Re: [Boost-build] third party libraries
From: Börje Granberg (borje.granberg_at_[hidden])
Date: 2010-03-19 03:17:42

I'm not sure what I want. I am thinking of the two alternatives you
proposed, but can I somehow trigger a make job from boost build?
This library (google protocol buffers) is also shared between several
of our products. Do you have any suggestion what the best way to solve
this, without duplicating the code? is prebuild binaries the best way
to go, or are there alternatives?

//Börje

2010/3/18 Johan Nilsson <r.johan.nilsson_at_[hidden]>:
>
> "Börje Granberg" <borje.granberg_at_[hidden]> skrev i meddelandet news:d04698ef1003151305k42f6f3banaa787a8935c32823_at_mail.gmail.com...
>> Hi,
>> Whats is the best way to include a third party library into your boost
>> build project. This third party library is not build with bjam/boost
>> build but an other famous build system. I'm not interested in
>> rewriting their build system and port it to boost build and I also
>> don't want to have it prebuilt on some network disc somewhere and just
>> link it into the project.
>
> If you don't want to build the third-party library from scratch using Boost.Build, and don't want to use prebuilt binaries (network drives or not) - what approach would you then like to take?
>
>> How have you included third party libraries into your boost build projects?
>
> It depends.
>
> It's usually pretty easy to include the source of the library inside your own source tree and create a jamfile to integrate the library build with your own project.
>
> We've also gone the other route and added pre-built binaries/libraries + header files for such libraries inside our own project, adding a Boost.Build target that "references" these artifacts. Check e.g. http://www.boost.org/doc/tools/build/doc/html/bbv2/tutorial/prebuilt.html for some details.
>
> The former approach is, IMHO, easier to use if you have a project that needs to support multiple compilers, multiple platforms and build libraries with many different variants that are ABI-incompatible.
>
> The latter is, still IMHO, easier to use if you are targeting e.g. a single compiler, single platform and is basically happy with plain "debug" and "release" variants. It can also still be easier to implement if the build process/environment of the third-party library is very complex.
>
> All of the above are of course generalizations, but might still be of some help.
>
> Regards / Johan
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>