Import SQLite 3.10.2.

third_party/sqlite/src/README.md

 <h1 align="center">SQLite Source Repository</h1>
 
 This repository contains the complete source code for the SQLite database
 engine.  Some test scripts are also include.  However, many other test scripts
 and most of the documentation are managed separately.
 
+If you are reading this on a Git mirror someplace, you are doing it wrong.
+The [official repository](https://www.sqlite.org/src/) is better.  Go there
+now.
+
 ## Compiling
 
 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:
 
@@ skipping 29 matching lines @@
     nmake /f Makefile.msc sqlite3.dll TOP=..\sqlite
     nmake /f Makefile.msc sqlite3.exe TOP=..\sqlite
     nmake /f Makefile.msc test TOP=..\sqlite
 
 There are several build options that can be set via the NMAKE command
 line.  For example, to build for WinRT, simply add "FOR_WINRT=1" argument
 to the "sqlite3.dll" command line above.  When debugging into the SQLite
 code, adding the "DEBUG=1" argument to one of the above command lines is
 recommended.
 
-SQLite does not require Tcl to run, but a Tcl installation is required
-by the makefiles (including those for MSVC).  SQLite contains a lot of
-generated code and Tcl is used to do much of that code generation.  The
-makefiles also require AWK.
+SQLite does not require [Tcl](http://www.tcl.tk/) to run, but a Tcl installation
+is required by the makefiles (including those for MSVC).  SQLite contains
+a lot of generated code and Tcl is used to do much of that code generation.
+The makefiles also require AWK.
 
 ## Source Code Tour
 
 Most of the core source files are in the **src/** subdirectory.  But
 src/ also contains files used to build the "testfixture" test harness;
 those file all begin with "test".  And src/ contains the "shell.c" file
 which is the main program for the "sqlite3.exe" command-line shell and
 the "tclsqlite.c" file which implements the bindings to SQLite from the
 Tcl programming language.  (Historical note:  SQLite began as a Tcl
 extension and only later escaped to the wild as an independent library.)
@@ skipping 18 matching lines @@
 Several of the C-language source files used by SQLite are generated from
 other sources rather than being typed in manually by a programmer.  This
 section will summarize those automatically-generated files.  To create all
 of the automatically-generated files, simply run "make target&#95;source".
 The "target&#95;source" make target will create a subdirectory "tsrc/" and
 fill it with all the source files needed to build SQLite, both
 manually-edited files and automatically-generated files.
 
 The SQLite interface is defined by the **sqlite3.h** header file, which is
 generated from src/sqlite.h.in, ./manifest.uuid, and ./VERSION.  The
-Tcl script at tool/mksqlite3h.tcl does the conversion.  The manifest.uuid
-file contains the SHA1 hash of the particular check-in and is used to generate
-the SQLITE_SOURCE_ID macro.  The VERSION file contains the current SQLite
-version number.  The sqlite3.h header is really just a copy of src/sqlite.h.in
-with the source-id and version number inserted at just the right spots.
-Note that comment text in the sqlite3.h file is used to generate much of
-the SQLite API documentation.  The Tcl scripts used to generate that
-documentation are in a separate source repository.
+[Tcl script](http://www.tcl.tk) at tool/mksqlite3h.tcl does the conversion.
+The manifest.uuid file contains the SHA1 hash of the particular check-in
+and is used to generate the SQLITE\_SOURCE\_ID macro.  The VERSION file
+contains the current SQLite version number.  The sqlite3.h header is really
+just a copy of src/sqlite.h.in with the source-id and version number inserted
+at just the right spots. Note that comment text in the sqlite3.h file is
+used to generate much of the SQLite API documentation.  The Tcl scripts
+used to generate that documentation are in a separate source repository.
 
 The SQL language parser is **parse.c** which is generate from a grammar in
 the src/parse.y file.  The conversion of "parse.y" into "parse.c" is done
 by the [lemon](./doc/lemon.html) LALR(1) parser generator.  The source code
 for lemon is at tool/lemon.c.  Lemon uses a
 template for generating its parser.  A generic template is in tool/lempar.c,
 but SQLite uses a slightly modified template found in src/lempar.c.
 
 Lemon also generates the **parse.h** header file, at the same time it
 generates parse.c. But the parse.h header file is
@@ skipping 51 matching lines @@
 prepared statements, the description of
 [how transactions work](http://www.sqlite.org/atomiccommit.html), and
 the [overview of the query planner](http://www.sqlite.org/optoverview.html).
 
 Unfortunately, years of effort have gone into optimizating SQLite, both
 for small size and high performance.  And optimizations tend to result in
 complex code.  So there is a lot of complexity in the SQLite implementation.
 
 Key files:
 
-  *  **sqlite3.h** - This file defines the public interface to the SQLite
+  *  **sqlite.h.in** - This file defines the public interface to the SQLite
      library.  Readers will need to be familiar with this interface before
      trying to understand how the library works internally.
 
   *  **sqliteInt.h** - this header file defines many of the data objects
      used internally by SQLite.
 
   *  **parse.y** - This file describes the LALR(1) grammer that SQLite uses
-     to parse SQL statements, and the actions that are taken at each stop
+     to parse SQL statements, and the actions that are taken at each step
      in the parsing process.
 
   *  **vdbe.c** - This file implements the virtual machine that runs
      prepared statements.  There are various helper files whose names
      begin with "vdbe".  The VDBE has access to the vdbeInt.h header file
      which defines internal data objects.  The rest of SQLite interacts
      with the VDBE through an interface defined by vdbe.h.
 
   *  **where.c** - This file analyzes the WHERE clause and generates
      virtual machine code to run queries efficiently.  This file is
      sometimes called the "query optimizer".  It has its own private
      header file, whereInt.h, that defines data objects used internally.
 
   *  **btree.c** - This file contains the implementation of the B-Tree
      storage engine used by SQLite.
 
   *  **pager.c** - This file contains the "pager" implementation, the
      module that implements transactions.
 
   *  **os_unix.c** and **os_win.c** - These two files implement the interface
      between SQLite and the underlying operating system using the run-time
      pluggable VFS interface.
 
+  *  **shell.c** - This file is not part of the core SQLite library.  This
+     is the file that, when linked against sqlite3.a, generates the
+     "sqlite3.exe" command-line shell.
+
+  *  **tclsqlite.c** - This file implements the Tcl bindings for SQLite.  It
+     is not part of the core SQLite library.  But as most of the tests in this
+     repository are written in Tcl, the Tcl language bindings are important.
+
+There are many other source files.  Each has a suscinct header comment that
+describes its purpose and role within the larger system.
+
 
 ## Contacts
 
 The main SQLite webpage is [http://www.sqlite.org/](http://www.sqlite.org/)
 with geographically distributed backup servers at
 [http://www2.sqlite.org/](http://www2.sqlite.org) and
 [http://www3.sqlite.org/](http://www3.sqlite.org).