Re: [boost] Use of third-party libraries

Subject: Re: [boost] Use of third-party libraries
From: Michael Shepanski (mps_at_[hidden])
Date: 2014-07-25 06:14:18

On 25/07/2014 5:49 PM, Gavin Lambert wrote:
> You're assuming that all backends must be built as part of the quince 
> tree.

Quite right: I assumed that, and I shouldn't have.

> What if I wanted to write a backend private to a particular 
> application and never intended to be published (perhaps it's some 
> proprietary data format rather than a "real" database)?
>
> If the core were always built, it could be used with a custom backend 
> that quince's jam file knows nothing about.

Fair enough, and we have since heard from Roland and Rob, so I think we 
have consensus: quince should get built regardless of whether any of the 
third-party libraries that I had in mind are already installed, and 
regardless of what is decided about shipping sqlite.

> (Provided that the core itself doesn't have to be modified to add a 
> new backend -- but I would hope that's true as it's part of standard 
> coding principles.)

I share your hope.  :)

When I look at quince+quince_postgresql+quince_sqlite, I can tell you 
that all the DBMS-specific code is in the hands of the backends. Quince 
has various classes with virtuals, and the backends have classes that 
override those virtuals to do backend-specific things. And I've tried to 
future-proof it, e.g. by putting "virtual" on all the functions that 
generate SQL phrases, whether they currently have backend-specific 
behaviour or not. Unfortunately, however, I don't have a formal 
specification of exactly which ways DBMSes are allowed vary, so I can't 
guarantee that that a new DBMS won't provoke some unanticipated, 
unimagined change to quince itself.

>> I'm coming around to Karsten Ahnert's idea that I should ship sqlite.
>> (I wouldn't call it a "default backend", as Karsten does, because
>> application code still has to make a choice -- but that's just a
>> quibble.).
>
> All of sqlite or just a connector to it?

I'll definitely be shipping a backend (aka connector) to sqlite. But to 
ship sqlite itself or not? That is the question I was soliloquizing about.

> I don't have any particular opinion on this either way, but bear in 
> mind that if you do the former, users may still wish to use a 
> different version of it (perhaps they need a bugfix from a newer 
> version than shipped with quince), and (especially if you don't 
> provide a way to do that) users will expect you to keep it up to date, 
> which increases maintenance costs slightly.

Hm.  On one hand, users are free to use their own backend library, which 
might be a very slightly modified version of quince_sqlite, to go with 
their own slightly different sqlite3.[ch]. And application code always 
has to say which backend library it is going to use for each database 
(see 
http://quince-lib.com/getting_started/creating_the_database_object.html). The 
only problem I see is if quince forces my chosen sqlite3.o into the 
link, leading to doubly-defined symbol errors. IANL (I Am Not A 
Linkerologist) but I suspect there is some solution based on ordering 
arguments to the linker, so that symbols in the user's sqlite3.o trump 
any in my sqlite3.o.

--- Michael