# mackyle/sqlite Source Build and Fossil Workflow

> mackyle/sqlite is an unofficial Git mirror of the SQLite source tree, intended for developers who need the engine's C sources rather than the SQLite user-facing library documentation. It preserves the source build workflow, while official Fossil check-in names remain the authoritative identifiers.

**mackyle/sqlite** — Unofficial git mirror of SQLite sources (see link for build instructions)

- Repository: https://github.com/mackyle/sqlite
- Website: https://repo.or.cz/sqlite.git
- Stars: 1,956 · Forks: 511
- Language: C
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mackyle-sqlite

## What mackyle/sqlite Contains

mackyle/sqlite solves source-distribution and build-inspection problems for developers who need the SQLite database engine itself. It is not an ORM, SQL client, or application database service. The repository contains the complete SQLite source code going back to 2000-05-29, along with tests and some documentation. The README explicitly says that additional tests and most documentation are managed separately, so this tree should not be treated as the full documentation or testing estate for SQLite.

The project is aimed at people who compile SQLite from C sources, work on the engine, build command-line tools, or need source code in a Git-oriented workflow. That audience includes engineers debugging a build, reviewing an engine change, producing an amalgamation, or building one of the repository's optional tools. The repository description identifies it as an unofficial Git mirror, while the README points readers to the official Fossil repository for the source of record. The default branch is master, and there are no GitHub releases associated with this mirror.

The boundary matters. The README is about building the source code, not teaching SQL usage or explaining SQLite from an application's perspective. The official SQLite documentation remains the reference for user-facing behavior. This mirror is more useful when the required artifact is source code or a build target than when the required artifact is a short installation guide for using SQLite in an application.

## Fossil Check-ins and Git Mirror Names

SQLite's source history is managed with Fossil, not Git. The official Fossil repository contains the urtext, and the README warns that Git mirror check-in names and other artifact names differ from the official names. The root manifest.uuid file identifies the official check-in. When communicating about a specific SQLite check-in, the README says to use the official name rather than the Git name.

That distinction affects reproducibility and provenance. A developer who sees a Git commit hash in mackyle/sqlite cannot assume that the same hash is the identifier to quote when discussing the corresponding upstream Fossil change. The repository includes .fossil-settings, which reflects the upstream Fossil-oriented structure, but the Git history still belongs to the mirror. The README also points to a Verifying Code Authenticity section for integrity checks when source was obtained from a secondary location.

This design is a compromise rather than a transparent one-to-one Git history. It gives engineers a Git-accessible copy, but it does not replace the official Fossil timeline for authoritative check-in identity. Teams that patch this mirror should record both the Git revision they inspected and the official SQLite check-in, including the value in manifest.uuid, whenever exact source correspondence matters.

## Unix-like Build Targets and Required Tools

The documented Unix-like build uses a separate build directory, runs the configure script from the source root, and invokes make targets. The README says gcc, make, and tcl-dev are necessary for the complete example. The core sqlite3 executable and sqlite3.c amalgamation can be built without TCL, but several other targets require a tclsh interpreter version 8.6 or later. The releasetest target has additional requirements, including valgrind.

The build is therefore layered. A developer who only needs the command-line program or the generated amalgamation can avoid TCL. A developer who wants the TCL extension, development tests, release tests, or other makefile targets needs a larger toolchain. The source tree also includes Makefile.linux-gcc as a generic fallback when configure does not work, although the README describes that as a file to copy and edit, not as a fully automated substitute.

The configure script uses autosetup. For debugging, the README shows the core developers' pattern of enabling all features and compiling with optimization disabled and debug symbols. For release builds, it shows a plain all-features configuration. Compile-time options can be passed through OPTIONS on the make command line. This gives source builders a visible control point without requiring edits to the main build files.

## Fetching SQLite with Fossil and Building the First Artifacts

The README gives Fossil as the direct way to access SQLite source, requiring Fossil version 2.0 or later. The initial checkout can take two or three minutes, while later updates are described as fast and bandwidth-efficient. The official Fossil repository is the source used by these commands. The commands below select the latest release or trunk, or identify a dated or versioned checkout.

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

This creates a working directory and opens the official Fossil repository. Once it completes, the documented update forms are:

```bash
fossil update trunk
fossil update release
fossil update trunk:2024-01-01
fossil update version-3.39.0
```

The first two select the latest trunk check-in or latest official release. The dated form selects the first trunk check-in after the stated date, and the version form selects a named release. The README also documents `fossil ui` for a web-based interface.

For the Git mirror itself, the repository can also be used as an ordinary Git source checkout. However, the README's build commands assume a source directory containing `configure`, `src/`, and the make infrastructure. In a sibling build directory, the documented sequence is:

```bash
apt install gcc make tcl-dev
tar xzf sqlite.tar.gz
mkdir bld
cd bld
../sqlite/configure
make sqlite3
```

The build should produce the `sqlite3` command-line tool. For a generated amalgamation, the documented target is `make sqlite3.c`. The source tarball URL is provided in the README, but the exact download command for a particular archive is not documented there, so the reader must obtain the archive from the stated SQLite source downloads page first.

## Build Options, Tools, and Verification Boundaries

The makefile exposes additional deliverables beyond the core executable. The README names `make sqldiff` for the SQL difference tool and `make sqlite3_analyzer` for the analyzer. It also documents `make tclextension-install` and test targets. These targets are useful for different engineering jobs, but they are not interchangeable. Building `sqlite3` proves only that the selected configuration produced the command-line tool; it does not verify that development or release tests can run.

Compile-time configuration is controlled by options passed to configure and by `OPTIONS=...` during make. The README's example omits a deprecated compile-time option:

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

The `--all` configure form enables all features. The `OPTIONS` assignment adds a compile-time definition for that invocation. For Windows, the README states that MSVC can compile SQLite and that a working TCL installation is needed only for tests.

Pull requests are normally not accepted because incorporating a contributed change could introduce copyright into a public-domain source tree. This is an unusual maintenance policy for a Git-hosted project. The mirror can be read and built, but changing it through an ordinary contribution workflow is not the documented path. Source authenticity and upstream change management remain tied to SQLite's own Fossil and copyright processes.

## When a Git Mirror Is the Wrong Source

mackyle/sqlite is the wrong choice for several ordinary SQLite adoption cases. An application developer who needs a library through a package manager or language binding should use that distribution mechanism. The README itself focuses on building the engine and refers readers to the online SQLite documentation for user-facing information. A source mirror does not solve deployment, driver configuration, or SQL usage.

It is also a poor fit when exact upstream history is the primary requirement. Because the README states that Git mirror artifact names differ from official Fossil names, a project that needs authoritative check-in correspondence should use the official Fossil repository. The mirror is useful when Git access is an operational requirement, but it introduces an identity boundary that engineers must preserve.

The source tree may also be the wrong abstraction for projects that need packaged binaries, signed release artifacts, or a supported distribution channel. The README provides links for source tarballs and precompiled binaries, but it does not claim that this Git mirror itself publishes GitHub releases. The repository has no GitHub releases according to its repository metadata. Teams should verify the intended source, licensing file, and target configuration before treating a locally built executable as a release artifact.

## Maintenance Signals and License Context

The repository is not archived. Its recorded last push was on 2026-08-05, which is a recent recorded update relative to the repository information available here. The README identifies SQLite source code as public domain and links to SQLite's copyright page for details. The repository metadata classifies the license as Other because GitHub cannot classify the custom license text, so the `LICENSE.md` file should be read directly when provenance or redistribution questions matter.

The public-domain status does not mean that the mirror is an official distribution channel. The README explicitly calls it a mirror and says official Fossil check-in names should be used when communicating about a check-in. For source provenance, record the official check-in from `manifest.uuid`, not only the mirror's Git commit. For build provenance, preserve the configure options, make options, compiler version, and target platform. The README documents the build mechanisms but does not promise that every Git commit corresponds to a named release.

Upgrade work is consequently source-level rather than version-package maintenance. A builder may need to compare the mirror's `VERSION`, inspect the official Fossil timeline, and account for changes in configure options or required tools. The repository's tests are present, but the README says more tests are managed separately, so passing a local target does not establish complete upstream validation.

## Conclusion

Developers who need to inspect, compile, or patch the SQLite engine should use this mirror when Git-based access is required, but they should verify important references with manifest.uuid and official Fossil check-in names. Projects that only need an application database driver should use an SQLite package or language binding instead of this source repository. The first build check is whether the platform's configure script, compiler, and required tools can produce sqlite3 and sqlite3.c.

## FAQ

### What is mackyle/sqlite used for?

It is an unofficial Git mirror of SQLite's complete C source tree, intended for developers who need to inspect or build the database engine and related tools. The README focuses on source builds rather than application-level SQLite usage.

### How do I obtain SQLite source using Fossil?

Install Fossil version 2.0 or later, then run `fossil open https://sqlite.org/src` from a chosen directory. The README documents updates for trunk, release, a date, or a named version such as `version-3.39.0`.

### Can I build sqlite3 without TCL?

Yes. The README says the core `sqlite3` executable and `sqlite3.c` amalgamation can be built without TCL. TCL development libraries are needed for targets such as `tclextension-install`, development tests, and release tests.

## Sources

- [Issues](https://github.com/mackyle/sqlite/issues)
- [mackyle/sqlite on GitHub](https://github.com/mackyle/sqlite)
- [Project website](https://repo.or.cz/sqlite.git)
- [README](https://github.com/mackyle/sqlite/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mackyle-sqlite