CodeVetter · Repo Unpack · System map
sqlite/sqlite
The library is a layered stack inside one process: SQL text enters the tokenizer, goes through a Lemon-generated LALR(1) parser into a code generator, is optimized by the `where*.c` planner, and is executed as bytecode by the VDBE, which reaches storage through B-Tree → Pager → WAL → VFS. There is no daemon and no network boundary in the core; the only OS boundary is the `sqlite3_vfs` interface, implemented by `os_unix.c`, `os_win.c`, `os_kv.c` (key/value / browser localStorage) and `memdb.c`. Build is driven by autosetup (JimTCL-compatible), not GNU Autoconf, with `main.mk` holding the real rules and `Makefile.msc` mirroring them for MSVC. Deployment shape is a static/shared library plus the amalgamation tarball, the `sqlite3` CLI, and auxiliary binaries (`sqldiff`, `sqlite3_rsync`, `sqlite3_analyzer`, `testfixture`, `fuzzcheck`). Version control is Fossil; `manifest`, `manifest.uuid`, and `.fossil-settings/` are Fossil artifacts carried into the Git mirror.
- The public C API is defined by the template `src/sqlite.h.in` (11,463 lines), which `tool/mksqlite3h.tcl` expands into the deliverable `sqlite3.h` by splicing in `VERSION` (3.54.0) and the SHA3 check-in id from `manifest.uuid`.
- `openDatabase()` in `src/main.c:3388` is the single funnel for `sqlite3_open`, `sqlite3_open_v2` and `sqlite3_open16`: it calls `sqlite3_initialize()`, decides thread-safety from `SQLITE_OPEN_NOMUTEX`/`FULLMUTEX` vs `sqlite3GlobalConfig.bFullMutex`, masks off internal-only open flags, allocates the `sqlite3` handle with `sqlite3MallocZero`, and enables lookaside plus `sqlite3_wal_autocheckpoint`.
- Compilation runs through `sqlite3LockAndPrepare()` (`src/prepare.c:854`), which takes `db->mutex`, calls `sqlite3BtreeEnterAll()` to hold every B-Tree mutex, and retries `sqlite3Prepare()` on `SQLITE_ERROR_RETRY` / `SQLITE_SCHEMA` up to `SQLITE_MAX_PREPARE_RETRY`.
- The VDBE is the execution boundary: `sqlite3VdbeExec()` (`src/vdbe.c:902`) is one giant `for(pOp=&aOp[p->pc]; 1; pOp++)` dispatch loop over 190 `case OP_*` handlers, and `tool/mkopcodeh.tcl` scrapes those `case OP_` lines out of `vdbe.c` to assign opcode numbers.
- Storage is layered strictly: `src/btree.c` (407KB, the largest file) exposes `sqlite3BtreeOpen/BeginTrans/Cursor/CommitPhaseOne/CommitPhaseTwo`, which sits on `src/pager.c`'s `sqlite3PagerOpen/Get/Write/CommitPhaseOne`, which in turn either journals or writes WAL frames via `src/wal.c`'s `sqlite3WalFrames`/`sqlite3WalCheckpoint`.
- The OS boundary is a registry of `sqlite3_vfs` objects; `os_unix.c` registers up to 12 named VFSes (`unix`, `unix-none`, `unix-dotfile`, `unix-excl`, `unix-flock`, `unix-afp`, `unix-nfs`, `unix-proxy`, …) via a `UNIXVFS()` macro table at `src/os_unix.c:8497`, each pairing a locking style with an `IOMETHODS()`-generated `sqlite3_io_methods` vtable.
- Alternative VFS backends ship in-tree: `src/memdb.c` registers a `memdb` VFS backing `sqlite3_serialize`/`sqlite3_deserialize`, and `src/os_kv.c` registers `kvvfs`, the key/value VFS used by the WASM/browser build.
- The build entrypoint is `./configure`, a 4-line shell wrapper that execs autosetup; `auto.def` drives it via `sqlite-configure canonical`, where `--dev` implies `--all --debug`, disables the amalgamation, and sets `CFLAGS=-O0 -g`.
- `main.mk` is the real makefile body (84KB): it defines `LIBOBJS0` (per-file objects) vs `LIBOBJS1 = sqlite3.o` (amalgamation) selected by `USE_AMALGAMATION`, and builds `sqlite3.c` by running `tool/mksqlite3c.tcl` over a generated `tsrc/` directory.
- The CLI shell is generated, not compiled directly: `src/shell.c.in` uses `INCLUDE ../ext/...` directives (processed by `tool/mkshellc.tcl`) to inline ~25 extension source files — sha1/shathree, base64/base85, decimal, ieee754, series, regexp, fileio, completion, appendvfs, zipfile, sqlar, vfstrace, diskused, plus the `expert`, `intck`, `recover` and `qrf` libraries.
- Auxiliary deliverables live in `tool/`: `sqldiff.c` (database diffing), `sqlite3_rsync.c` (rsync-like replication over SSH), `sqlite3_analyzer.c.in` (space analysis, paired with `tool/spaceanal.tcl`), `showdb.c`/`showwal.c`/`showjournal.c` (file-format forensics), and `lemon.c` (the parser generator itself).
- A second, reduced build tree exists under `autoconf/` for the shipped amalgamation tarball (its own `auto.def`, `Makefile.in`, `Makefile.msc`, `Makefile.fallback`, plus a `tea/` TCL Extension Architecture build), and `tool/srctree-check.tcl` enforces that `autoconf/Makefile.msc` stays in sync with the top-level `Makefile.msc`.
- There is no CI configuration in the repository — no `.github/`, `.gitlab-ci.yml`, or Travis file exists; the only VCS metadata is `.fossil-settings/` (`binary-glob`, `empty-dirs`, `ignore-glob`) plus the Fossil `manifest`, consistent with the README's statement that the Git remote is a mirror.
- Language-binding boundaries ship in-tree: `src/tclsqlite.c` (150KB) exposes `Sqlite3_Init`/`DbMain`/`DbObjCmd` as a TCL package, `ext/jni/src/c/sqlite3-jni.c` with 58 Java files provides JNI bindings, and `ext/wasm/api/` provides an Emscripten/WASM JS API with OPFS-backed VFS variants.