sqlite

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 is to visit the SQLite Forum at https://sqlite.org/forum/. Anonymous postings are permitted. For bug reports, please use the SQLite bugs forum at https://sqlite.org/bugs. 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 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 test ;# 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 makefil