Re: [boost] Use of third-party libraries

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

- The backend-specific source code should be in subdirs of 
boost/libs/quince.

- 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/bin.v2/libs/math/build/*/*/*/*/*.lib.

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

Thanks,
--- Michael