|
Boost : |
Subject: Re: [boost] Use of third-party libraries
From: Roland Bock (rbock_at_[hidden])
Date: 2014-07-23 10:28:49
On 2014-07-23 15:13, Michael Shepanski 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).
I guess that you would not want to maintain the backends for the umpteen
databases. I don't know what the best approach is. Maybe you provide
backends for the most popular databases and let others provide backends
for the rest? I don't think that there is a precedent for this situation.
Personally, I would prefer the individual repositories. It makes it
easier to distribute the work load and you would not have to decide
which databases to include in the main repositories and which to keep
out. It would therefore also emphasize the vendor neutrality of the main
library.
Regards,
Roland
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk