Boost logo

Boost :

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 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at