Checkout Tools
  • last updated 59 mins ago
Constraints: committers
Constraints: files
Constraints: dates
When compiling SQLite, enable the SQLITE_OMIT_WAL compile-time option.

We don't use WAL (write-ahead logging) feature of SQLite, but just keeping it

enabled has a visible I/O performance penalty, because SQLite has to check if

the write-ahead log file is present on disk. In a couple of my experiments,

disabling this feature resulted in a ~10% faster `svn st` on a large working


* subversion/libsvn_subr/sqlite3wrapper.c


When compiling SQLite, set the SQLITE_DEFAULT_MEMSTATUS=0 compile-time option.

This is the recommended option that is not enabled by default. Setting it to

zero avoids using a mutex (and thus suffering a performance penalty) during

every sqlite3_malloc() call, where this mutex is used to properly update the

allocations stats. We don't use sqlite3_status(), so set this option to zero.


* subversion/libsvn_subr/sqlite3wrapper.c


Silence a deprecation warning from amalgamated SQLite on macOS.

* subversion/libsvn_subr/sqlite3wrapper.c: Ignore -Wdeprecated-declarations.

On OSX, ranlib complains loudly about object files with no symbols.

To silence it, put at least one global scope symbol in every file.

* subversion/libsvn_subr/config_win.c

(svn__fake__config_win): Define when WIN32 is not defined.

* subversion/libsvn_subr/win32_crashrpt.c

(svn__fake__win32_crashrpt): Likewise.

* subversion/libsvn_subr/win32_crypto.c

(svn__fake__win32_crypto): Again.

* subversion/libsvn_subr/win32_xlate.c

(svn__fake__win32_xlate): And again.

* subversion/libsvn_subr/sqlite3wrapper.c

(svn__fake__sqlite3wrapper): Define when SVN_SQLITE_INLINE is not defined.

  1. … 4 more files in changeset.
Make the SQLite amalgamated build work with recent versions of the

SQLite amalgamation.

At some point in the not too distant past, the SQLite devs arbitrarily

decided to change their feature checks (some 14k lines deep within the

amalgamated sqlite3.c file) from #ifdef to #if conditions. Of course,

to make things more interesting, the visible ones at the top of that

file are still #ifdef's.

* subversion/libsvn_subr/sqlite3wrapper.c

(SQLITE_OMIT_DEPRECATED): Define this symbol to 1.

Shut up a bunch of warnings from SQLite Amalgamation.

I get no warnings from CLang now, but GCC still spits a bunch out for me

since you simply can't turn them off with pragmas. Our only option is

to figure out how to pass '-w' to GCC when building this file.

* subversion/libsvn_subr/sqlite3wrapper.c:

Don't bother with the push or pop. Effectively nothing is in this file but

the SQLite Amalgamation so no reason to turn them back on. Since the other

pragmas have been supported since GCC 4.2 let more compilers benefit from

reduced warnings. CLang has shorten-64-to-32 so disable it for it not just

Apple's fork of GCC. Add two CLang specific warnings.


* subversion/libsvn_subr/sqlite.c

(internal_open): Avoid SQLITE_DEFAULT_FILE_PERMISSIONS here.

(svn_sqlite__hotcopy): Remove avoidance code.

* subversion/libsvn_fs_fs/rep-cache.c

(open_rep_cache): Remove avoidance code.

* subversion/libsvn_wc/wc_db_util.c

(svn_wc__db_util_open_db): Remove avoidance code.

* subversion/libsvn_subr/sqlite3wrapper.c

(SQLITE_DEFAULT_FILE_PERMISSIONS): Set for amalgamation builds.

  1. … 3 more files in changeset.
Work around a problem on older OS X systems: sqlite3.c includes

<libkern/OSAtomic.h>, which uses 'inline' and thus cannot be compiled

with -std=c89 that we are using for all files.

* subversion/libsvn_subr/sqlite3wrapper.c

(toplevel): Define 'inline' as '__inline__' (which gcc accepts even in c89

mode) during a pre-emptive inclusion of <libkern/OSAtomic.h>.

* subversion/tests/libsvn_wc/wc-queries-test.c

(toplevel): Likewise.

Patch by: mattiase

  1. … 1 more file in changeset.
* subversion/libsvn_subr/sqlite3wrapper.c

* tools/server-side/fsfs-stats.c

* tools/dev/fsfs-access-map.c

* tools/dev/fsfs-reorg.c

(svn:eol-style): Set to native.

  1. … 3 more files in changeset.
Temporarily revert part of the change from the tweak-build-take-two branch that

moved the expected location of the SQLite amalgamation directory and used

relative paths to include those files, because it conflicts with the use of

--with-sqlite to locate an amalgamation directory outside the build tree.

Note that this can cause builds to fail if non-amalgamated SQLite is found

elsewhere on the include path before the amalagamated files.


- Change expected location of the amalgamation package.

* build/ac-macros/sqlite.m4:

- Look for $abs_srcdir/sqlite-amalgamation.

- Do add include paths to wherever the amalgamation was found.

* subversion/libsvn_subr/sqlite.c, subversion/libsvn_subr/sqlite3wrapper.c,

subversion/tests/libsvn_wc/wc-queries-test.c: Do not use relative paths

to include amalgamation sources.

  1. … 7 more files in changeset.
Reintegrate tweak-build-take-two branch to trunk.

Summary of changes:

** Split standards-compliance mode and maintainer mode compiler flags

out of CFLAGS, so that compilation command lines that do not

generate (too many) warnings or are not forced to comply with ISO

C '90 can be constructed without having to resort to stripping

individual flags out of CFLAGS.

$ svn diff -r1424288:1424822 \

^/subversion/branches/tweak-build-take-two/ \

^/subversion/branches/tweak-build-take-two/aclocal.m4 \

^/subversion/branches/tweak-build-take-two/build/ac-macros/compiler.m4 \


** Now that warning and standards-compliance mode macros are no

longer part of CFLAGS, stop stripping them in the Swig wrapper

configury, except for Ruby, which is more delicate.

$ svn diff -r1424329:1425040 \


** Allow optimization and debugging to coexist, including in

maintainer mode, adding a new configure option

--enable-optimize. Neither --enable-optimize nor --enable-debug

will override any optimization or debugging flags set by the user

in C(XX)FLAGS at configure time. If debugging and optimization are

enabled at the same time, we will try to use -O1, then -O; if

debuggin is not enabled, we will try -O2 first.

$ svn diff -c1424860 \


** Remove an obsolete autoconf macro that was not used anywhere and

is superceded with SVN_CFLAGS_ADD_IFELSE.

$ svn diff -c1424297 \


** Move the sqlite-amalgamation directory from the root of the source tree

under subversion/include/private to make include paths safer from

possible collision with sqlite include files from other install locations.

$ svn diff -c1425050 \


** Allow a user to set a custom set of compiler flags at configure time that

are used for Subversion sources, but not, e.g., Swig-generated sources,

like this:

$ ./configure CUSERFLAGS=--flags-for-C CXXUSERFLAGS=--flags-for-C++

$ svn diff -c1425086 \


  1. … 14 more files in changeset.
Followup to r1417014: what "works" on OSX with a silly LibAPR will not

necessarily work in a more normal situation.

* subversion/libsvn_subr/sqlite3wrapper.c

(svn_sqlite3__api_initialize, svn_sqlite3__api_config): Manually export

two extra SQLite functions that the vtable does not contain. Their lack

was not apparent on my OSX with stock libapr, because that pulls in -lsqlite.

(svn_sqlite3__api_funcs): Rename from sqlite3_api.

* subversion/libsvn_subr/sqlite.c: Import tese new symbols from sqlite3wrapper.

(sqlite3_api, sqlite3_initialize, sqlite3_config): Locally rename the

imported symbols.

  1. … 1 more file in changeset.
Cherry-pick r1407642 from the wc-collate-path branch, with the following effect:

On the wc-collate-path branch: Move the amalgamated SQLite import to

a separate file to avoid having to wade through tons of warnings from

sqlite3.c every time I change some header that sqlite.c uses.

* subversion/libsvn_subr/sqlite3wrapper.c: New file. When SVN_SQLITE_INLINE

is defined, include the amalgamated sqlite3.c here. Also define

SQLITE_OMIT_DEPRECATED to not include deprecated APIs in the vtable.

(sqlite3_api): Exported API vtable normally used by SQLite extensions.

* subversion/libsvn_subr/sqlite.c: When SVN_SQLITE_INLINE is defined,

define SQLITE_OMIT_DEPRECATED and include sqlite3ext.h to get the

vtable devfinition, then ...

(extern sqlite3_api): ... import the actual vtable from sqlite3wrapper.

  1. … 2 more files in changeset.