On 25/07/2014 18:53, Michael Shepanski wrote:
Assuming there is no backend for the database I am interested in, I might want to have quince core in order to develop that backend. I therefore think that quince core should always be built.
In that case, sooner or later you're going to have to tweak quince's jam file, to make the building of your backend contingent on the presence of some third-party library (fron MySQL or Oracle or whatever).
You're assuming that all backends must be built as part of the quince tree. 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. (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'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 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.