<h1 align="center">SQLite Source Repository</h1>

This repository contains the complete source code for the SQLite database engine going back to 2000-05-29. The tree includes many tests and some documentation, though additional tests and most documentation are managed separately.

See the on-line documentation for more information about what SQLite is and how it works from a user's perspective. This README file is about the source code that goes into building SQLite, not about how SQLite is used.

Version Control

SQLite sources are managed using Fossil, a distributed version control system that was specifically designed and written to support SQLite development. The Fossil repository contains the urtext.

If you are reading this on GitHub or some other Git repository or service, then you are looking at a mirror. The names of check-ins and other artifacts in a Git mirror are different from the official names for those objects. The official names for check-ins are found in a footer on the check-in comment for authorized mirrors. The official check-in name can also be seen in the manifest.uuid file in the root of the tree. Always use the official name, not the Git-name, when communicating about an SQLite check-in.

If you pulled your SQLite source code from a secondary source and want to verify its integrity, there are hints on how to do that in the Verifying Code Authenticity section below.

Contacting The SQLite Developers

The preferred way to ask questions or make comments about SQLite or to report bugs against SQLite is to visit the SQLite Forum at https://sqlite.org/forum/. Anonymous postings are permitted.

If you think you have found a bug that has security implications and you do not want to report it on the public forum, you can send a private email to drh at sqlite dot org.

Public Domain

The SQLite source code is in the public domain. See https://sqlite.org/copyright.html for details.

Because SQLite is in the public domain, we do not normally accept pull requests, because if we did take a pull request, the changes in that pull request might carry a copyright and the SQLite source code would then no longer be fully in the public domain.

Obtaining The SQLite Source Code

Source code tarballs or ZIP archives are available at:

Latest trunk check-in.
Latest release
For other check-ins, browse the project timeline and click on the check-in hash of the check-in you want to download. On the resulting "info" page, click one of the options to the right of the "Downloads:" label in the "Overview" section near the top.

To access sources directly using Fossil, first install Fossil version 2.0 or later. Source tarballs and precompiled binaries for Fossil are available at https://fossil-scm.org/home/uv/download.html. Fossil is a stand-alone program. To install, simply download or build the single executable file and put that file someplace on your $PATH or %PATH%. Then run commands like this:

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

The initial "fossil open" command will take two or three minutes. Afterwards, you can do fast, bandwidth-efficient updates to the whatever versions of SQLite you like. Some examples:

    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

Or type "fossil ui" to get a web-based user interface.

Compiling for Unix-like systems

First create a directory in which to place the build products. It is recommended, but not required, that the build directory be separate from the source directory. Cd into the build directory and then from the build directory run the configure script found at the root of the source tree. Then run "make". See the compile-for-unix.md document for more detail.

For example:

    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 devtest                  ;#  Run development tests
    make releasetest              ;#  Run full release tests
    make sqlite3_analyzer         ;#  Builds the "sqlite3_analyzer" tool

See the makefile for additional targets. For debugging builds, the core developers typically run "configure" with options like this:

    ../sqlite/configure --all --debug CFLAGS='-O0 -g'

For release builds, the core developers usually do:

    ../sqlite/configure --all

Core deliverables (sqlite3.c, sqlite3) can be built without a TCL, but many makefile targets require a "tclsh" TCL interpreter version 8.6 or later. The "tclextension-install" target and the test targets that follow all require TCL development libraries too. ("apt install tcl-dev"). It is helpful, but is not required, to install the SQLite TCL extension (the "tclextension-install" target) prior to running tests. The "releasetest" target has additional requirements, such as "valgrind".

On "make" command-lines, one can add "OPTIONS=..." to specify additional compile-time options over and above those set by ./configure. For example, to compile with the SQLITE_OMIT_DEPRECATED compile-time option, one could say:

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

The configure script uses autosetup. If the configure script does not work out for you, there is a generic makefile named "Makefile.linux-gcc" in the top directory of the source tree that you can copy and edit to suit your needs. Comments on the generic makefile show what changes are needed.

Compiling for Windows Using MSVC

On Windows, everything can be compiled with MSVC. You will also need a working installation of TCL if you want to run tests, though TCL is not required if you just want to build SQLite itself. See the compile-for-windows.md document for additional information about how to install MSVC and TCL and configure your build environment.

If you want to run tests, you need to let SQLite know the location of your TCL library, using a command like this:

    set TCLDIR=c:\Tcl

SQLite itself does not contain any TCL code, but it does use TCL to run tests. You may need to install TCL development libraries in order to successfully complete some makefile targets. It is helpful, but is not required, to install the SQLite TCL extension (the "tclextension-install" target) prior to running tests.

The source tree contains a "make.bat" file that allows the same "make" commands of Unix to work on Windows. In the following, you can substitute "nmake /f Makefile.msc" in place of "make", if you prefer to avoid this BAT file:

    make sqlite3.exe
    make sqlite3.c
    make sqldiff.exe
    #### Targets below require TCL development libraries ####
    make tclextension-install
    make devtest
    make releasetest
    make sqlite3_analyzer.exe

There are many other makefile targets. See comments in Makefile.msc for details.

As with the unix Makefile, the OPTIONS=... argument can be passed on the nmake command-line to enable new compile-time options. For example:

    make OPTIONS=-DSQLITE_OMIT_DEPRECATED sqlite3.exe

Source Tree Map

src/ - This directory contains the primary source code for the SQLite core. For historical reasons, C-code used for testing is also found here. Source files intended for testing begin with "test". The tclsqlite3.c and tclsqlite3.h files are the TCL interface for SQLite and are also not part of the core.
test/ - This directory and its subdirectories contains code used for testing. Files that end in ".test" are TCL scripts that run tests using an augmented TCL interpreter named "testfixture". Use a command like "make testfixture" to build that augmented TCL interpreter, then run individual tests using commands like "testfixture test/main.test". This test/ subdirectory also contains additional C code modules and scripts for other kinds of testing.
tool/ - This directory contains programs and scripts used to build some of the machine-generated code that goes into the SQLite core, as well as to build and run tests and perform diagnostics. The source code to the Lemon parser generator is found here. There are also TCL scripts used to build and/or transform source code files. For example, the tool/mksqlite3h.tcl script reads the src/sqlite.h.in file and uses it as a template to construct the deliverable "sqlite3.h" file that defines the SQLite interface.
ext/ - Various extensions to SQLite are found under this directory. For example, the FTS5 subsystem is in "ext/fts5/". Some of these extensions (ex: FTS3/4, FTS5, RTREE) might get built

Sqlite

Install / Use

README