Boost logo

Boost :

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
boost/libs/numeric/*/ .

- 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.

--- Michael

Boost list run by bdawes at, gregod at, cpdaniel at, john at