SQLite

The purpose of the autosetup branch is to explore porting of the SQLite build process from the venerable GNU Autotools to Steve Bennett's Autosetup. This branch does not represent a project-level commitment to actually follow through with such a port. Whether or not that will be feasible, given this project's unusually wide end-user footprint and compatibility concerns, remains to be seen.

Perceived advantages of such a port:

• Autosetup lives entirely in the project source tree, so is not subject to incompatibilities when developers upgrade their Autotools.

• Autosetup is far simpler to work with. Where Autotools is based on a mix of GNU m4 and POSIX shell code, Autosetup uses only TCL, and includes a single-file distribution of JimTCL for use on systems which don't have tclsh installed (noting that JimTCL shares the same maintainer as Autosetup). The SQLite project has a long history of using TCL for its build-time and testing tooling, making TCL a natural choice for a project configuration language.

  • Closely related: through the intended support lifetime of SQLite, it seems likely that we will need to migrate to other build processes at least twice. We won't, long term, realistically be able to cling to the version of the Autotools which we currently restrict ourselves to.

• Ease of maintenance. The autotools-based build files are low-maintenance only in the sense that we don't edit them unless it's absolutely necessary to do so. Autosetup, on the other hand, is comprised entirely of comparatively user-friendly TCL, so is more welcoming.

• As of 2024-09-27, all of the TCL-generated source code can be generated using the Autosetup-provided copy of JimTCL. i.e. the tree no longer needs an external TCL binary to build but does for the tests, as those rely on the project's TCL SQLite bindings.

Potential disadvantages:

• It does not automagically handle the build-tool portability, in particular for some of the more obscure target platforms, e.g. AIX or QNX. Autosetup assumes POSIX-style platforms and it is, as of this writing, as yet unclear whether it will be suitable for use on some of the outlier platforms which SQLite's build process has historically supported. If not, a fallback option would be to provide static makefiles for such platforms, similar to how is currently done for Windows platforms.

• How much effort will be required to get out-of-tree and cross-compilation working is currently unclear. (Out-of-tree builds work "out of the box" so long as a tiny bit of care is taken in writing the Makefile rules.)

• Because of differences in how Autotools and Autosetup handle configure script switches, some switches will need to be renamed or change semantics. i.e. it is unavoidable that some downstream automated build processes would need to be ever-so-slightly adapted. A concrete example of this is the --enable-tempstore flag: Autosetup internally applies special meaning to the --enable- and --disable- flag prefixes, forcing such flags to be boolean-only, which necessitates a rename of that flag to --with-tempstore in this build process so that it may retain the same semantics that it has historically had. Similarly, Autosetup uses --debug for its own purposes, necessitating a rename of that build flag.

  • That said: build processes, as a rule, are not guaranteed interfaces.

Sidebars:

• SQLite's sibling project, the Fossil SCM, has used Autosetup since July of 2011 with no issues, so we know that it works well and is painless to upgrade.

• Both the SQLite and Fossil projects have a long history of positive interactions with Autosetup's creator, which of course biases us somewhat in his favor.