SQLite's Git mirror: Fossil check-in names, TCL-gated make targets, and a build that runs from a sibling directory

Every Git check-in name in this mirror is the wrong one to cite

The tree here goes back to 2000-05-29 and is a mirror, not the place the work happens. SQLite sources are managed with Fossil, a distributed version control system written specifically to support SQLite development, and the Fossil repository contains what the README calls the urtext. The consequence for anyone reading this Git tree is stated directly: the names of check-ins and other artifacts in a Git mirror are different from the official names for those objects.

Two official names exist for you to use. One sits in a footer on the check-in comment for authorized mirrors, and the other is the check-in name in the manifest.uuid file in the root of the tree, which you can see listed at the top level of this repository alongside manifest and manifest.tags. When you file a bug or discuss a change, quote that official name, not the Git hash. If you pulled the source from a secondary source, the Verifying Code Authenticity section of the README explains how to check what you actually received. Practically, this means a commit hash from this mirror cannot be pasted into a bug report as a reproducible reference, and two people comparing builds from this mirror and from Fossil may be looking at identical code under different names.

Pull requests are declined on copyright grounds, so forks carry the patch

The SQLite source code is in the public domain, with details at sqlite.org/copyright.html. Public domain status is exactly why the project does not normally accept pull requests: a contributed change might carry a copyright, and taking it would mean the source is no longer fully public domain. Read that as a hard constraint on the contribution model rather than a review policy.

The channels that remain open are named. Questions and comments about SQLite go to the SQLite Forum at sqlite.org/forum, where anonymous postings are permitted. Bug reports go to the SQLite bugs forum at sqlite.org/bugs rather than to a Git issue tracker. A bug with security implications that you do not want on a public forum can go by private email to drh at sqlite dot org.

For a team that needs a change, that leaves three realistic options: keep the patch outside the tree and carry it at build time, wait for a trunk check-in that does the same thing, or maintain a fork with the divergence cost on your side. The upstream timeline is browsable at sqlite.org/src/timeline, so you can see whether something similar already landed before you decide which of the three you are taking on.

fossil open takes minutes because the history goes back decades

The route that gives you upstream object names is Fossil, and it requires Fossil version 2.0 or later. You put the single executable somewhere on your $PATH or %PATH%, then clone into a local directory:

mkdir -p ~/sqlite
cd ~/sqlite
fossil open https://sqlite.org/src

The README warns that the initial open takes two or three minutes, after which updates are fast and bandwidth-efficient. The update targets are the interesting part, because they express intent rather than hashes:

fossil update trunk             ;# latest trunk check-in
fossil update release           ;# latest official release
fossil update trunk:2024-01-01  ;# First trunk check-in after 2024-01-01
fossil update version-3.39.0    ;# Version 3.39.0

That gives you a date or a version name where this mirror gives you a commit id, and fossil ui opens a web-based interface over the same repository. If you skip Fossil entirely, tarballs and ZIP archives are still available for the latest trunk check-in and for the latest release, and for any other check-in you can browse the project timeline, open that check-in's info page, and use the options to the right of the Downloads label. The cost of the Fossil route is time and one more tool; the benefit is that your build provenance matches what upstream names.

Two make targets build the core, and everything else wants tclsh 8.6

The Unix build is a configure script at the root of the source tree plus make, run from a build directory that the README recommends be separate from the source directory, though not required. The full sequence, including the tools it expects:

apt install gcc make tcl-dev  ;#  Install the necessary build tools
tar xzf sqlite.tar.gz         ;#  Unpack the source tree into "sqlite"
mkdir bld                     ;#  Build happens in a sibling directory
cd bld                        ;#  Change to the build directory
../sqlite/configure           ;#  Run the configure script
make sqlite3                  ;#  The "sqlite3" command-line tool
make sqlite3.c                ;#  The "amalgamation" source file
make sqldiff                  ;#  The "sqldiff" command-line tool
#### Targets below require tcl-dev ####
make tclextension-install     ;#  Install the SQLite TCL extension
make test                     ;#  Run development tests
make releasetest              ;#  Run full release tests

The split is explicit: the core deliverables sqlite3.c and sqlite3 build without a TCL interpreter, but many makefile targets require tclsh version 8.6 or later, the tclextension-install target and the test targets that follow it require TCL development libraries, and releasetest adds requirements such as valgrind. Installing the TCL extension before running tests is helpful but not required. On a build machine without TCL you get the library and the shell, and no way to run the test suite, so a CI job that claims to validate SQLite changes is either installing TCL or not testing.

Compile-time options after configure only arrive through OPTIONS=

The configure script decides the baseline set of compile-time options, and it uses autosetup. Anything beyond that set can be handed to make directly, because the makefile command line accepts an OPTIONS= variable that adds to what configure chose. The README gives one worked example:

./configure --all
make OPTIONS=-DSQLITE_OMIT_DEPRECATED sqlite3

SQLITE_OMIT_DEPRECATED removes the deprecated interfaces from the build entirely, so code that still calls them stops compiling rather than warning. That is the mechanism the README shows: options over and above those set by ./configure are added with OPTIONS= on the make command line. Two more build shapes are worth knowing: the core developers run configure with debug settings for debugging, ../sqlite/configure --all --debug CFLAGS='-O0 -g', and plain ../sqlite/configure --all for release builds.

The documented fallback makefile is not the generic makefile in the tree

If configure does not work for your environment, the README points to a generic makefile at the top directory of the source tree that you can copy and edit, with comments showing what changes are needed. The name it gives is Makefile.linux-gcc. The top level of this repository, however, lists Makefile.linux-generic along with Makefile.in, Makefile.msc, main.mk, make.bat, auto.def, and the autosetup and autoconf directories. So the generic makefile named in the prose and the generic makefile present in the mirror are not the same name, and a reader who takes the filename literally will not find it.

That is a small thing. The top level also holds an autosetup-based configure script for Unix-like systems, Makefile.in, main.mk, make.bat and Makefile.msc. On Windows the README states that everything can be compiled with MSVC, and that a working TCL installation is needed if you want to run tests, though TCL is not required just to build. Further detail sits in doc/compile-for-unix.md, and AGENTS.md is present at the top level for automated tooling. If your build fails in configure, diff the tree's makefile names against the prose before assuming your toolchain is the problem.

There are no GitHub releases here, and the documentation is mostly elsewhere

This repository has no GitHub releases, which is consistent with everything else about it being a mirror. Version identity lives upstream: in Fossil, in the VERSION file at the top of the tree, and in the manifest files that Fossil uses. When you want a release, the README's download paths are the latest release tarball and the latest trunk check-in, not a tag on this mirror.

The same separation applies to everything except code. The tree includes many tests and some documentation, and the README says additional tests and most documentation are managed separately. What is here is the code: src, test, tool, ext, contrib, mptest, art, and doc. So a reader looking for the format specification, the query planner notes, or the full test corpus will find fragments rather than the whole thing, and the pointer to the on-line documentation at sqlite.org is there for a reason. This README is explicit that it is about the source code that goes into building SQLite, not about how SQLite is used.

None of that means the mirror is stale. The last push landed on 2026-11-02 on the default branch master, so trunk activity is arriving; the gap is in release tagging and documentation, not in the code.

Editorial conclusion

This mirror suits anyone who wants to read, build, or audit SQLite source, and the configure plus make path produces sqlite3 and the amalgamation without a TCL interpreter. It is the wrong place to look for release history, for the documentation, or for a contribution path, since versioning lives in Fossil and in the VERSION file, most documentation is managed outside the tree, and pull requests are not normally accepted. Before you build or pin anything, decide whether you need the Fossil names rather than the Git ones, confirm a tclsh of version 8.6 or later is present if you intend to run the test targets, and take release tarballs from sqlite.org rather than from a mirror snapshot.

Frequently asked questions

Official sources

1. Issues
2. README
3. sqlite/sqlite on GitHub