managing library dependencies with Boost.Build and C++

Question

I want to develop a project which can be built on a bunch of different platforms. The project code will be in C++, what's the the best way to manage libraries?

I plan on using bjam as the build system because I'm going to be depending on Boost and their unit testing framework as well.

The two dependencies are Boost itself and FLTK.

The possibilities that come to mind for library management are:

1. include build artifacts (binaries) and headers for all supported platforms in-tree
2. include complete source for all library dependencies in-tree, and somehow script them as dependencies
3. A combination of 1 and 2, like node.js does with v8
4. inform the user that they need to build the libraries themselves and then have them on the PATH or in some special directory, like libcurl does with its dependencies
5. depend on *nix build tools (i.e. libtool) mozilla style and then tell the user they have to use MSYS to build on windows

What is the best approach here? The project will probably not grow beyond a few thousand lines over the next six months, but I want to make the right choice here so that I don't have to come back and switch everything around later.

Answer 1

This is a subjective answer.

First, about Boost: once Boost is built, in whatever way, you don't need to use bjam. Therefore you can use any build system that suits you, while requiring certain libraries to be on the system or in certain paths, however they are built. As a side note, much of boost is header-only (even the unit testing framework can be used header-only IIRC, but it is recommended to use the library version). Let's assume you need the boost binaries.

The best way to handle the project IMO, is to use your own chosen build system that suits you most for your own project, and require the dependencies (boost) "prebuilt". How they are prebuilt depends on each dependency; some might use the same build system you choose, others will use their own build systems. Some will be made for all platforms, and, for example, some will compile on windows but not have the best build system suitable for windows. If they are small libraries, you can integrate them into your build system, otherwise just think of them as a "dependency" that the developer will "somehow" have to have before building your project. The "somehow" here is to be explained in a README.

So for example, I use cmake for my project, but use boost and a few other libraries in my project. cmake allows me to generate project files for MSVC, C::B, GNUMake etc., however I can't hope to have all my dependencies also using cmake. For the very small, stable, libraries, I can make a cmake project for them, and then things are really simple. For the larger or more volatile libraries, it's best to leave each to their own build system. Volatile libraries change often, so if you build anything "custom" for them, you will have to constantly adapt your "customizations" to changes in the library. For each library I use, I have some cmake variable, like BOOST_LIB_INCLUDE_PATHS and BOOST_LIB_LIBRARY_PATHS and BOOST_LIB_LIBRARIES, which can be defined to the their values by the developer compiling my project. cmake does provide some magic library searching capabilities, but I found such magic to be ugly hacks, so I explicitly require the paths to be set as variables.

You can decide yourself whether to provide the sources to these libraries; nothing wrong with that, especially where you want to depend on a particular version of a library. But scripting them as dependencies can become a big mess, on top of the maintenance for volatile libraries.

However, I know when the Google Chromium project gets built, something like a hundred libraries are downloaded, checked out, built and linked. Chromium uses GYP as a build system IIRC.