Hey Richard!
(long time, no see... I still remember our fun Foo session a couple
years ago...)
Yup. Subversion has grown a SQLite dependency. It is "light" in 1.6,
but we are movin to a serious dependency upon it for 1.7.
Our build system allows for using SQLite that has been installed, a
specific SQLite directory, or an amalgamation file. For the latter, we
compile it privately into our libsvn_subr library (where your user
noted the problem).
We chose to allow options other than amalgamation because we'd heard
feedback, "let the sysadmins upgrade sqlite independently on their
system", rather than pinning svn to whatever-we-shipped. IOW, if we
ship an amalgamation, then it becomes *our problem* when bugs appear
in sqlite, and we need to spin up a new release.
Your thoughts are most welcome! SQLite is (now) a key technology
within Subversion. We'd certainly like to be a Good User.
For your user with the problem, please redirect them to
users_at_subversion.tigris.org, and we'll help them out.
Cheers,
-g
On Mon, May 4, 2009 at 15:56, D. Richard Hipp <drh_at_hwaci.com> wrote:
> We received the following post on the SQLite mailing list today:
>
> http://article.gmane.org/gmane.comp.db.sqlite.general/46505
>
> 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
> drh_at_sqlite.org
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2056719
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2056828
Received on 2009-05-04 16:06:52 CEST