Lines Matching refs:in

17 other artifacts in a Git mirror are different from the official
19 found in a footer on the check-in comment for authorized mirrors.
20 The official check-in name can also be seen in the `manifest.uuid` file
21 in the root of the tree.  Always use the official name, not  the
22 Git-name, when communicating about an SQLite check-in.
25 verify its integrity, there are hints on how to do that in the
33   *  Latest trunk check-in as
44      tag or hash prefix in place of "release" in the URLs of the previous
46      to locate the check-in desired, click on its information page link,
66         fossil update trunk   ;# latest trunk check-in
73 First create a directory in which to place
82         mkdir bld                ;#  Build will occur in a sibling directory
93 "Makefile.linux-gcc" in the top directory of the source tree that you
126 Most of the core source files are in the **src/** subdirectory.  The
138 Test scripts and programs are found in the **test/** subdirectory.
139 Additional test code is found in other source repositories.
144 Full-text search engine is in **ext/fts3**.  The R-Tree engine is in
155 other sources rather than being typed in manually by a programmer.  This
163 generated from src/sqlite.h.in, ./manifest.uuid, and ./VERSION.  The
165 The manifest.uuid file contains the SHA3 hash of the particular check-in
168 just a copy of src/sqlite.h.in with the source-id and version number inserted
169 at just the right spots. Note that comment text in the sqlite3.h file is
171 used to generate that documentation are in a separate source repository.
173 The SQL language parser is **parse.c** which is generated from a grammar in
182 corresponding to opcodes in the "VDBE" virtual machine.  The opcodes.h
206 way of using SQLite in a larger application.  Combining all individual
215 tool/mksqlite3c.tcl script is run to copy them all together in just the
226 individual source file exceeds 32K lines in length.
230 SQLite is modular in design.
232 for details. Other documents that are useful in
241 for small size and high performance.  And optimizations tend to result in
242 complex code.  So there is a lot of complexity in the current SQLite
243 implementation.  It will not be the easiest library in the world to hack.
247   *  **sqlite.h.in** - This file defines the public interface to the SQLite
257      in the parsing process.
284   *  **shell.c.in** - This file is not part of the core SQLite library.  This
286      "sqlite3.exe" command-line shell.  The "shell.c.in" file is transformed
290      is not part of the core SQLite library.  But as most of the tests in this
291      repository are written in Tcl, the Tcl language bindings are important.
293   *  **test*.c** - Files in the src/ folder that begin with "test" go into
295      an enhanced Tcl shell.  The testfixture.exe program runs scripts in the
311 older files) for every source file in the repository.