Subject: Re: [boost] Use of third-party libraries
From: Michael Shepanski (mps_at_[hidden])
Date: 2014-07-23 22:35:50
On 24/07/2014 9:23 AM, Gavin Lambert wrote:
> I'm not sure exactly how it works but from the modularisation
> discussion it's evident that Boost's library structure supports
> "sub-libraries" (aka submodules) that exist in the same repository but
> are built separately.
> I suspect what you'll probably want to do would be to create a "core"
> submodule that each of the separate backend submodules depend on (each
> of those also depending on a single external library as needed), and
> then finally a "front-end" top level that doesn't directly depend on
> anything but the core, but allows any of the DB-specific backends to
> be used with it.
Currently the "quince" library contains both the "core" and "front-end"
components. I figured that nobody would want one without the other. What
advantage do you see in separating them?
> Boost.Numeric seems to be an existing example of a library divided
> into submodules.
> Boost.Math seems to be an example of a library without submodules that
> nevertheless builds multiple output libraries.
> I'm not sure which style is "preferred".
Putting together your response and all the other responses, I'm starting
to stabilize on the following set of views:
- I should put just one new directory into boost/libs, i.e.
- The backend-specific source code should be in subdirs of
- These subdirs should be separate git modules, in the manner of
- The output should consist of a core quince .lib file, and separate
.lib files for each backend, laid out in the manner of
- boost/libs/quince/Jamfile.v2 should somehow detect which third-party
libraries are present, and build the corresponding backend libraries. If
there are more than zero, it should build the core quince library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk