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