Boost logo

Boost :

Subject: Re: [boost] Use of third-party libraries
From: Roland Bock (rbock_at_[hidden])
Date: 2014-07-24 05:56:14


On 2014-07-24 04:35, Michael Shepanski wrote:
> 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.

Sounds good to me except for the last item.

Assuming there is no backend for the database I am interested in, I
might want to have quince core in order to develop that backend. I
therefore think that quince core should always be built.

Cheers,

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk