On Wed, Jan 14, 2009 at 9:42 AM, Greg Stein <gstein_at_gmail.com> wrote:
> Nope... note the use of SQLITE_API defined as "static". All of the
> sqlite functions are static to libsvn_subr/sqlite.c. No naming
> contention at all!
Hmm, good point. =)
I still believe that the change should be reverted.
> I'd prefer to see an amalgamation build over a ./sqlite build. Tho I
> guess with the latter, it can be independently rev'd independent of
> what amalgamation we include into our build.
>
> I'm curious about the ENOTSUP error though. I thought sqlite was very portable.
I get the following warnings on Solaris:
autogen.sh output:
...
Creating build-outputs.mk...
WARNING: "config.h" header not found, file subversion/libsvn_subr/sqlite3_c.h
WARNING: "sseInt.h" header not found, file subversion/libsvn_subr/sqlite3_c.h
...
compile-time:
"../../subversion/subversion/libsvn_subr/sqlite3_c.h", line 19420:
warning: integer overflow detected: op "<<"
(E_INTEGER_OVERFLOW_DETECTED)
"../../subversion/subversion/libsvn_subr/sqlite3_c.h", line 19437:
warning: integer overflow detected: op "<<"
(E_INTEGER_OVERFLOW_DETECTED)
"../../subversion/subversion/libsvn_subr/sqlite3_c.h", line 19532:
warning: integer overflow detected: op "<<"
(E_INTEGER_OVERFLOW_DETECTED)
"../../subversion/subversion/libsvn_subr/sqlite3_c.h", line 19533:
warning: integer overflow detected: op "<<"
(E_INTEGER_OVERFLOW_DETECTED)
"../../subversion/subversion/libsvn_subr/sqlite3_c.h", line 25649:
warning: statement not reached (E_STATEMENT_NOT_REACHED)
"../../subversion/subversion/libsvn_subr/sqlite3_c.h", line 32380:
warning: statement not reached (E_STATEMENT_NOT_REACHED)
In order to remove these, we'd need to 'fork' SQLite. I'd really
rather not do that.
On *most* current OSes, they already have a suitable SQLite version
installed. On the *nix-side, I think we're really only hearing about
complaints regarding ancient RHEL releases (RHEL4 is entering
'critical security fixes only' mode in March). If we simply add the
auto-fu for building from ./sqlite, I think we'd solve those concerns
even for folks on ancient OSes.
Our policy has been to include dependencies separately and *not*
include them directly in the tree. Why should SQLite be different?
I'd rather that we just add a ./sqlite dir to the -deps tarball when
1.6 rolls around and we'd be fine.
I also strongly dislike the idea that we're going to be using a custom
version of SQLite that doesn't match what the OS provider gives - this
will bust any easy ability for users to investigate/debug the SQLite
databases when needed via the 'sqlite' et al tools. (Yes, they do so
at their own risk; but I think it'll be crucial as we encounter issues
in the new WC code in the long-run.) Since it will be on us to
constantly upgrade what is in our tree (and backport constantly), it's
going to be a PITA to keep things in sync with what is available of
sqlite.org.
> Anyways... looks like a blend of restoring-autoconf and the amalg
> build should do the trick. Just needs some volunteers...
As I said, I was already partially through adding the bundle support.
Now that glasser blew away the files w/o giving any heads-up, I've got
tree conflicts. =( -- justin
Received on 2009-01-14 19:44:00 CET