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

Re: [PATCH/RFC v3] Optionally allow binaries to run against older SQLite

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sun, 06 Nov 2011 09:28:54 +0200

On Friday, November 04, 2011 1:24 AM, "Jonathan Nieder" <jrnieder_at_gmail.com> wrote:
> [[[
> Introduce a --enable-sqlite-compatibility-version=X.Y.Z option for
> ./configure to allow people building Subversion to specify how old the
> system being deployed on might be. Setting the compatibility version
> to an older version turns on code in subversion that works around
> infelicities in older versions and relaxes the version check ("SQLite
> compiled for 3.7.4, but running with 3.7.3") at initialization time.
>
> If the compat version is set to a version before the minimum supported
> version (3.6.18), the build will fail early so the person building can
> adjust her expectations.
>
> The default for the compat version is the currently installed version,
> so there should be no change in behavior for users not passing this
> option to the configure script.
>
> * subversion/include/private/svn_dep_compat.h
> (SVN_SQLITE_MIN_VERSION_NUMBER, SVN_SQLITE_MIN_VERSION): Set to
> SQLITE_VERSION_NUMBER, SQLITE_VERSION if undefined.
> (SQLITE_VERSION_AT_LEAST): Check SVN_SQLITE_MIN_VERSION_NUMBER instead
> of SQLITE_VERSION_NUMBER.
>
> * subversion/libsvn_subr/sqlite.c (init_sqlite): Check sqlite version
> against SVN_SQLITE_MIN_VERSION_NUMBER instead of SQLITE_VERSION_NUMBER.
>
> * configure.ac: Provide a --enable-sqlite-compatibility-version switch
> that sets SVN_SQLITE_MIN_VERSION_NUMBER and SVN_SQLITE_MIN_VERSION.
>
> * build/ac-macros/sqlite.m4
> (SVN_SQLITE_VERNUM_PARSE): Make it reusable (in particular for
> configure.ac), by taking a version string and a variable to store the
> corresponding version number as arguments.
> (SVN_SQLITE_MIN_VERNUM_PARSE): Simplify by calling
> SVN_SQLITE_VERNUM_PARSE.
> (SVN_SQLITE_PKG_CONFIG): Adapt SVN_SQLITE_VERNUM_PARSE call to the new
> calling convention.
> ]]]
>
> +++ subversion/include/private/svn_dep_compat.h (working copy)
> @@ -107,6 +107,32 @@
> #endif /* SERF_VERSION_AT_LEAST */
>
> +/**
> + * By default, if libsvn is built against one version of SQLite
> + * and then run using an older version, svn will error out:
...
> +#ifndef SVN_SQLITE_MIN_VERSION_NUMBER
> +#define SVN_SQLITE_MIN_VERSION_NUMBER SQLITE_VERSION_NUMBER
> +#define SVN_SQLITE_MIN_VERSION SQLITE_VERSION
> +#endif /* SVN_SQLITE_MIN_VERSION_NUMBER */
> +

Hmm. I wonder if we should be more paranoid here when checking/defining
the macros. Probably I'm just being overly careful.

> #ifdef __cplusplus
> Index: configure.ac
> ===================================================================
> --- configure.ac (revision 1197399)
> +++ configure.ac (working copy)
> @@ -172,6 +172,18 @@
> SVN_LIB_SQLITE(${SQLITE_MINIMUM_VER}, ${SQLITE_RECOMMENDED_VER},
> ${SQLITE_URL})
>
> +AC_ARG_ENABLE(sqlite-compatibility-version,
> + AS_HELP_STRING([--enable-sqlite-compatibility-version=X.Y.Z],
> + [Allow binary to run against older SQLite]),

Perhaps have the help string mention how ARG is used?
"Allow binary to run against SQLite as old as ARG"

Also, should you forbid passing this arg when linking against a static SQLite?

> + [sqlite_compat_ver=$enableval],[sqlite_compat_ver=no])
> +
> +if test -n "$sqlite_compat_ver" && test "$sqlite_compat_ver" != no; then
> + SVN_SQLITE_VERNUM_PARSE([$sqlite_compat_ver],
> + [sqlite_compat_ver_num])
> + CFLAGS="-DSVN_SQLITE_MIN_VERSION='\"$sqlite_compat_ver\"' $CFLAGS"
> + CFLAGS="-DSVN_SQLITE_MIN_VERSION_NUMBER=$sqlite_compat_ver_num $CFLAGS"
> +fi
> +
> dnl Set up a number of directories ---------------------
>
> dnl Create SVN_BINDIR for proper substitution

I've committed the sqlite3.m4 part in r1198169. The rest looks good
too, but I'm going to wait a day or two before committing the remainder,
to let people join the conversation if they have feedback.

Thanks,

Daniel
Received on 2011-11-06 08:29:47 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.