[PATCH] Update sqlite3 build process, add +fts3 variant

[kballard (Lily Ballard)]

The sqlite3 project strongly recommends using the amalgamation tarball instead of the complete source tarball. The attached patch updates the build process to do so. The only drawback is the manpage is missing from this tarball (a ticket has been filed with the sqlite3 project), but as Mac OS X provides its own manpage, I don't think this is a big issue.

Using the amalgamation tarball gives two benefits. The first is, according to the sqlite3 documentation, this should give a performance increase to the sqlite3 library. The second is using this makes it easy to enable the FTS3 module, which is now provided via the +fts3 variant.

Here is the commit message I wrote:

Update the build process for sqlite3

Convert sqlite3 to use the amalgamation tarball. Not only is this
strongly encouraged by the sqlite3 project, it is also suggested that
this could show a performance improvement.

Update the configure flags. The amalgamation tarball means --disable-tcl
is no longer necessary. The readline flags have been updated into
--enable-readline and READLINE_LIBS. --enable-load-extension has been
removed as it was renamed (but a bug in the configure script makes it unusable).

Introduce a new variant fts3, which enables the FTS3 module.

[kballard (Lily Ballard)]

Patch for sqlite3 Portfile

[mww@…]

Regarding interprocedural optimization, gcc prior to 4.1 only supports inlining, so the edge of the amalgamation source should be minimal at best. Later versions of gcc and llvm may gain more from this source but as the bottleneck of sqlite is normally IO, the effect should again be minimal (if any). On PPC this might actually reduce performance as the larger binary (due to inlining) requires more memory; Apple compiles its sources for PPC optimized for size because of this.

The ​sqlite homepage states that the amalgamation source is for integration (...contains everything you need to integrate SQLite into a larger project);

To enable the FTS3 module, the amalgamation sources are not required. Should we add a fts3 variant nevertheless?

[kballard (Lily Ballard)]

Yes, we definitely need an FTS3 variant. I looked into adapting the source tarball (rather than the amalgamation) but that would require significantly more changes to the Portfile.

Also, the ​Download page states that the amalgamation source is the recommended way to get sqlite3 (This is the recommended source distribution for all Unix and unix-like platforms.). However, even more importantly, it states very clearly that you should not use the source tree tarball:

The Makefile and configure script in this tarball are not supported. Their use is not recommented. The SQLite developers do not use them. You should not use them either. If you want a configure script and an automated build, use either the amalgamation tarball or TEA tarball instead of this one. To build from this tarball, hand-edit one of the template Makefiles in the root directory of the tarball and build using your own customized Makefile.

Given that paragraph, I strongly recommend using the amalgamation tarball even if it has the possibility of reducing performance slightly on PPC.

[(none)]

Milestone Port Enhancements deleted

[blb@…]

See also #21875.

[jmroot (Joshua Root)]

FTS3 added in r70595, and as of 3.7.4 (r75036) there's an apparently supported autoconf-based amalgamation.