Re: [boost] Use of third-party libraries

Subject: Re: [boost] Use of third-party libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-07-23 10:12:09

On Wed, Jul 23, 2014 at 5:13 PM, Michael Shepanski <mps_at_[hidden]> wrote:
> On 23/07/2014, at 10:54 PM, Roland Bock <rbock_at_[hidden]> wrote:
>
>> On 2014-07-23 14:09, Michael Shepanski wrote:
>>>
>>>
>>>
>>> Also I'm thinking that my approach of having separate backend
>>> libraries is not right. The idea had been that a user decides which
>>> backend library to download and build, but that is not going to be
>>> happening a boost context. Everything should be in the "quince"
>>> library, every user downloads it all, and its build script decides
>>> which components to build.
>> Hi Michael,
>>
>> There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird
>> and BerceleyDB and I don't know how many else, but a lot. To me it does
>> not sound like a good idea to have all backends in one giant library.
>
> I don't have any strong opinions about this, and I'm happy to go with the conventional approach -- as soon as I know what that is.
>
> Taking your lead and daring to imagine a future with quince backend code for a great many DBMSes, I ask: what do you propose? Would there be a separate boost/libs/quince_xyz for each DBMS xyz?
>
> Also, what disadvantages do you see in the "one giant library" approach (assuming that its build script chooses which parts to compile, based on the presence of third-party libraries).

Monolithic library is not a good solution for distributed binaries.
Once compiled library will require all the DBMSes it was compiled
against and not support any other. E.g. on Linux such library package
will pull all DBMS packages, even though the user might need just one.

I think separate optionally compiled binaries (one backend per binary)
is the preferred solution. That doesn't mean the library source code
and docs must be split, though.