[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r35241 - in trunk: . build/ac-macros subversion/include/private subversion/libsvn_subr

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: Wed, 14 Jan 2009 09:21:58 -0800

On Wed, Jan 14, 2009 at 8:43 AM, David Glasser <glasser_at_davidglasser.net> wrote:
> Use an "amalgamated" in-line version of sqlite3 instead of linking
> against an external library. This change makes it much easier to
> build Subversion on systems which have a pre-3.4.x sqlite3 installed
> globally.
>
> (It has the downside that there is no longer an option to use an
> external sqlite3 at all, which may be desired by some packagers.
> Personally, I prefer "everyone can build Subversion, but some
> packagers might be a little sad about theoretical aspects" over "some
> core Subversion developers (OK, at least just me) haven't been able
> to build trunk Subversion for months, but packagers have their warm
> fuzzy feelings". I do hope that somebody who loves autoconf more than
> I goes in and gives the option of using an external sqlite3. Though
> maybe this time the sqlite.m4 could check that the discovered sqlite3
> is new enough, maybe?)

-1.

In order to use a static version, we have to rename all symbols to
avoid conflicts as APR-util can also bring in sqlite. Therefore, we
have now introduced symbol/version collisions that can cause failures
at run-time and indeterminate behavior.

FWIW, I was already working on a patch to do the external config when
./sqlite exists - as no one added ./sqlite bundled-support to
configure. IMO, that's a far more elegant solution... -- justin
Received on 2009-01-14 18:22:20 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.