We received the following post on the SQLite mailing list today:
I have not looked at the SVN code, but it would appear that in order
to compile SVN one must first install SQLite libraries on the build
system. In other words, it appears that SVN has a dependency SQLite.
May I suggest you do away with this dependency. Grab a copy of the
SQLite amalgamation source file and its header (sqlite3.c and
sqlite3.h) for whatever version of SQLite works for you, and check in
those files as part of your own source tree. Adjust your makefiles so
that they compile the built-in sqlite3.c instead of trying to link
against a library (which may or may not be available on the system.)
This will make it that much easier for people to compile SVN.
Upgrading is easy. When you decide you want to use the latest version
of SQLite (because it is faster or has some new feature you want)
simple download the latest sqlite3.c and sqlite3.h from the SQLite
website, drop them into your own source tree, and recompile.
This will also make SVN more resistant to breakage if somebody updates
the system SQLite library - since SVN will not depend on the system
SQLite library but will have its own. We work hard to keep SQLite
fully compatible from one release to the next. But sometimes a bug
fix in SQLite will break systems that depend on the old buggy
behavior. So it never hurts to stick with a specific version of
SQLite unless you are 100% sure that your use of SQLite never depends
on any undefined or ill-defined behavior.
PHP, Mozilla, Python, Perl, Fossil, Tcl, and many other projects
manage SQLite this way. All commercial projects that we are aware of
use SQLite this way. The SQLite library is not that big. It will not
bloat your source tree. But it will tend to make your users happier.
D. Richard Hipp
Received on 2009-05-04 15:58:28 CEST