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
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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk