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.
David, question:
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
need it?
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
Stefan
Received on 2009-01-14 18:25:41 CET