On Wed, Jan 14, 2009 at 05:09:35PM +0000, Stefan Sperling wrote:
> On Wed, Jan 14, 2009 at 08:43:29AM -0800, David Glasser wrote:
> > For efficiency reasons, the system has converted the large body of this message into an attachment.
> > Message-ID: <200901141643.n0EGhTnJ007832_at_svn2.sjc.collab.net>
> > Date: Wed, 14 Jan 2009 08:43:29 -0800
> > From: glasser_at_tigris.org
> > To: svn_at_subversion.tigris.org
> > Subject: svn commit: r35241 - in trunk: . build/ac-macros subversion/include/private subversion/libsvn_subr
> > Content-Type: text/plain; charset=UTF-8
> > Reply-To: dev_at_subversion.tigris.org, glasser_at_tigris.org
> > Author: glasser
> > Date: Wed Jan 14 08:43:29 2009
> > New Revision: 35241
> > Log:
> > 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.
> Is this amalgamated version of sqlite supposed to be portable?
> It breaks the build on OpenBSD.
Can we back out this commit, and you rework this change so that we use
an external sqlite by default, but have some configure flag like
--use-internal-sqlite to link the amalgamated version for those who
I think that would be a better solution.
Binary package maintainers may want to link to the system sqlite anyway.
At least with my OpenBSD devel/subversion port maintainer hat on, I'd say
that I myself would rather have the subversion package on OpenBSD use
the system sqlite, which is recent enough:
$ pkg_info | grep sqlite3
sqlite3-3.6.4p0 embedded SQL implementation
Received on 2009-01-14 18:25:41 CET