On Fri, Apr 04, 2008 at 08:48:53AM -0400, D. Richard Hipp wrote:
> The way we build the TCL interface that is on the download
> page is that the TCL interface code becomes part of the
> amalgamation and the whole thing is compiled as a single
> translation unit. I cannot imagine why anyone would want
> to do it differently.
I can, since I wanted to do it differently when integrating SQLite3 into
Solaris.
There's several reasons:
1a) Shared libraries are a way of life in Solaris (and other OSes), and
avoiding object code duplication is, specifically, a goal.
1b) Patches to libsqlite3 need only patch that, not also libtclsqlite3,
and even if libtclsqlite3 needs patching, the lack of object code
duplication will make the patches smaller (though perhaps also less
compressible).
2) In the very unlikely (but not infeasible) event that one should have
an application that uses Tcl and C interfaces to access the same
SQLite DB then all hell will break loose if libtclsqlite has its own
internal copy of libsqlite -- there will be two distinct copies of
libsqlite object code in one process accessing the same DB.
3) Bindings of SQLite3 for other languages don't have the same luxury
of calling private libsqlite functions. On principle neither should
the TCL bindings. If nothing else it will help keep the
libtclsqlite code clean and separable.
(2) is not so farfetched. I used to maintain a proprietary (now open
source) product called UName*It that did just this, though with a
different, also proprietary DB. The current maintainers have expressed
a desire to use SQLite instead, which would result in (2) unless they
did even more surgery to UName*It than they thought they'd have to.
> But just yesterday I had a chat conversation
> with an engineer at Novell/SuSE and he could not understand
> why anybody would want to do it my way - since that would
> me there were two complete copies of the SQLite library on
> disk. Different strokes for different folks, I guess...
We have that view as well. It's quite prevalent.
The problem is that as more operating systems bundle SQLite your notion
of embeddable gets tested. Does embeddable mean that the object code is
statically linked into the application? Or that the DB isn't a
networked DB? IMO: the latter.
I strongly advise that libtclsqlite3 should have no dependencies on
private interfaces in libsqlite3.
Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
