Skip to content
/ sqlite Public

Official Git mirror of the SQLite source tree

License

View license
9k stars 1.4k forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

sqlite/sqlite

BranchesTags

Repository files navigation

SQLite Source Repository

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".

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