endif
sqlite3-api.jses += $(dir.api)/sqlite3-vfs-opfs.c-pp.js
sqlite3-api.jses += $(dir.api)/sqlite3-vfs-opfs-sahpool.c-pp.js
-sqlite3-api.jses += $(dir.api)/sqlite3-api-cleanup.js
#
# extern-post-js* and extern-pre-js* are files for use with
At the center of the onion is `sqlite3-api.js`, which gets generated
by concatenating the following files together in their listed order:
-- **`sqlite3-api-prologue.js`**\
+- **`sqlite3-api-prologue.js`**
Contains the initial bootstrap setup of the sqlite3 API
objects. This is exposed as a function, rather than objects, so that
the next step can pass in a config object which abstracts away parts
of the WASM environment, to facilitate plugging it in to arbitrary
WASM toolchains. The bootstrapping function gets removed from the
global scope in a later stage of the bootstrapping process.
-- **`../common/whwasmutil.js`**\
+- **`../common/whwasmutil.js`**
A semi-third-party collection of JS/WASM utility code intended to
replace much of the Emscripten glue. The sqlite3 APIs internally use
these APIs instead of their Emscripten counterparts, in order to be
toolchains. It is "semi-third-party" in that it was created in order
to support this tree but is standalone and maintained together
with...
-- **`../jaccwabyt/jaccwabyt.js`**\
+- **`../jaccwabyt/jaccwabyt.js`**
Another semi-third-party API which creates bindings between JS
and C structs, such that changes to the struct state from either JS
or C are visible to the other end of the connection. This is also an
independent spinoff project, conceived for the sqlite3 project but
maintained separately.
-- **`sqlite3-api-glue.js`**\
+- **`sqlite3-api-glue.js`**
Invokes functionality exposed by the previous two files to flesh out
low-level parts of `sqlite3-api-prologue.js`. Most of these pieces
involve populating the `sqlite3.capi.wasm` object and creating
`sqlite3.capi.sqlite3_...()` bindings. This file also deletes most
global-scope symbols the above files create, effectively moving them
into the scope being used for initializing the API.
-- **`<build>/sqlite3-api-build-version.js`**\
+- **`<build>/sqlite3-api-build-version.js`**
Gets created by the build process and populates the
`sqlite3.version` object. This part is not critical, but records the
version of the library against which this module was built.
-- **`sqlite3-api-oo1.js`**\
+- **`sqlite3-api-oo1.js`**
Provides a high-level object-oriented wrapper to the lower-level C
API, colloquially known as OO API #1. Its API is similar to other
high-level sqlite3 JS wrappers and should feel relatively familiar
to anyone familiar with such APIs. It is not a "required component"
and can be elided from builds which do not want it.
-- **`sqlite3-api-worker1.js`**\
+- **`sqlite3-api-worker1.js`**
A Worker-thread-based API which uses OO API #1 to provide an
interface to a database which can be driven from the main Window
thread via the Worker message-passing interface. Like OO API #1,
this is an optional component, offering one of any number of
potential implementations for such an API.
- - **`sqlite3-worker1.js`**\
+ - **`sqlite3-worker1.js`**
Is not part of the amalgamated sources and is intended to be
loaded by a client Worker thread. It loads the sqlite3 module
and runs the Worker #1 API which is implemented in
`sqlite3-api-worker1.js`.
- - **`sqlite3-worker1-promiser.js`**\
+ - **`sqlite3-worker1-promiser.js`**
Is likewise not part of the amalgamated sources and provides
a Promise-based interface into the Worker #1 API. This is
a far user-friendlier way to interface with databases running
in a Worker thread.
-- **`sqlite3-vfs-helper.js`**\
+- **`sqlite3-vfs-helper.js`**
Installs the `sqlite3.vfs` namespace, which contain helpers for use
by downstream code which creates `sqlite3_vfs` implementations.
-- **`sqlite3-vtab-helper.js`**\
+- **`sqlite3-vtab-helper.js`**
Installs the `sqlite3.vtab` namespace, which contain helpers for use
by downstream code which creates `sqlite3_module` implementations.
-- **`sqlite3-vfs-opfs.c-pp.js`**\
+- **`sqlite3-vfs-opfs.c-pp.js`**
is an sqlite3 VFS implementation which supports the [Origin-Private
FileSystem (OPFS)][OPFS] as a storage layer to provide persistent
storage for database files in a browser. It requires...
- - **`sqlite3-opfs-async-proxy.js`**\
+ - **`sqlite3-opfs-async-proxy.js`**
is the asynchronous backend part of the [OPFS][] proxy. It
speaks directly to the (async) OPFS API and channels those
results back to its synchronous counterpart. This file, because
it must be started in its own Worker, is not part of the
amalgamation.
-- **`sqlite3-vfs-opfs-sahpool.c-pp.js`**\
+- **`sqlite3-vfs-opfs-sahpool.c-pp.js`**
is another sqlite3 VFS supporting the [OPFS][], but uses a
completely different approach than the above-listed one.
-- **`sqlite3-api-cleanup.js`**\
- The previous files do not immediately extend the library. Instead
- they add callback functions to be called during its
- bootstrapping. Some also temporarily create global objects in order
- to communicate their state to the files which follow them. This file
- cleans up any dangling globals and runs the API bootstrapping
- process, which is what finally executes the initialization code
- installed by the previous files. As of this writing, this code
- ensures that the previous files leave no more than a single global
- symbol installed - `sqlite3InitModule()`. When adapting the API for
- non-Emscripten toolchains, this "should" be the only file, of those
- in this list, where changes are needed. The Emscripten-specific
- pieces described below may also require counterparts in any as-yet
- hypothetical alternative build.
+The previous files do not immediately extend the library. Instead they
+install a global function `sqlite3ApiBootstrap()`, which downstream
+code must call to configure the library for the current JS/WASM
+environment. Each file listed above pushes a callback into the
+bootstrapping queue, to be called as part of `sqlite3ApiBootstrap()`.
+Some files also temporarily create global objects in order to
+communicate their state to the files which follow them. Those
+get cleaned up vi `post-js-footer.js`, described below.
+
+Adapting the build for non-Emscripten toolchains essentially requires packaging
+the above files, concatated together, into that toolchain's "JS glue"
+and, in the final stage of that glue, call `sqlite3ApiBootstrap()` and
+return its result to the end user.
**Files with the extension `.c-pp.js`** are intended [to be processed
with `c-pp`](#c-pp), noting that such preprocessing may be applied
The following Emscripten-specific files are injected into the
build-generated `sqlite3.js` along with `sqlite3-api.js`.
-- **`extern-pre-js.js`**\
+- **`extern-pre-js.js`**
Emscripten-specific header for Emscripten's `--extern-pre-js`
flag. As of this writing, that file is only used for experimentation
purposes and holds no code relevant to the production deliverables.
-- **`pre-js.c-pp.js`**\
+- **`pre-js.c-pp.js`**
Emscripten-specific header for Emscripten's `--pre-js` flag. This
file overrides certain Emscripten behavior before Emscripten does
most of its work.
-- **`post-js-header.js`**\
+- **`post-js-header.js`**
Emscripten-specific header for the `--post-js` input. It opens up,
but does not close, a function used for initializing the library.
-- (**`sqlite3-api.js`** gets sandwiched between these ↑ two
- ↓ files.)
-- **`post-js-footer.js`**\
+- **`sqlite3-api.js`** gets sandwiched between these ↑ two
+ ↓ files.
+- **`post-js-footer.js`**
Emscripten-specific footer for the `--post-js` input. This closes
- off the function opened by `post-js-header.js`.
-- **`extern-post-js.c-pp.js`**\
+ off the function opened by `post-js-header.js`. This file cleans up
+ any dangling globals and runs `sqlite3ApiBootstrap()`. As of this
+ writing, this code ensures that the previous files leave no more
+ than a single global symbol installed - `sqlite3InitModule()`.
+
+- **`extern-post-js.c-pp.js`**
Emscripten-specific header for Emscripten's `--extern-post-js`
flag. This file is run in the global scope. It overwrites the
Emscripten-installed `sqlite3InitModule()` function with one which
+/*
+ 2022-07-22
+
+ The author disclaims copyright to this source code. In place of a
+ legal notice, here is a blessing:
+
+ * May you do good and not evil.
+ * May you find forgiveness for yourself and forgive others.
+ * May you share freely, never taking more than you give.
+
+ ***********************************************************************
+
+ This file is the tail end of the sqlite3-api.js constellation,
+ intended to be appended after all other sqlite3-api-*.js files so
+ that it can finalize any setup and clean up any global symbols
+ temporarily used for setting up the API's various subsystems.
+
+ In terms of amalgamation code placement, this file is appended
+ immediately after the final sqlite3-api-*.js piece. Those files
+ cooperate to prepare sqlite3ApiBootstrap() and this file calls it.
+ It is run within a context which gives it access to Emscripten's
+ Module object, after sqlite3.wasm is loaded but before
+ sqlite3ApiBootstrap() has been called.
+
+ Because this code resides (after building) inside the function
+ installed by post-js-header.js, it has access to state set up by
+ pre-js.c-pp.js and friends.
+*/
+try{
+ /* Config options for sqlite3ApiBootstrap(). */
+ const bootstrapConfig = Object.assign(
+ Object.create(null),
+ globalThis.sqlite3ApiBootstrap.defaultConfig, // default options
+ globalThis.sqlite3ApiConfig || {}, // optional client-provided options
+ /** The WASM-environment-dependent configuration for sqlite3ApiBootstrap() */
+ {
+ memory: ('undefined'!==typeof wasmMemory)
+ ? wasmMemory
+ : EmscriptenModule['wasmMemory'],
+ exports: ('undefined'!==typeof wasmExports)
+ ? wasmExports /* emscripten >=3.1.44 */
+ : (Object.prototype.hasOwnProperty.call(EmscriptenModule,'wasmExports')
+ ? EmscriptenModule['wasmExports']
+ : EmscriptenModule['asm']/* emscripten <=3.1.43 */)
+ }
+ );
+
+ sqlite3InitScriptInfo.debugModule("Bootstrapping lib config", bootstrapConfig);
+
+ /**
+ For purposes of the Emscripten build, call sqlite3ApiBootstrap().
+ Ideally clients should be able to inject their own config here,
+ but that's not practical in this particular build constellation
+ because of the order everything happens in. Clients may either
+ define globalThis.sqlite3ApiConfig or modify
+ globalThis.sqlite3ApiBootstrap.defaultConfig to tweak the default
+ configuration used by a no-args call to sqlite3ApiBootstrap(),
+ but must have first loaded their WASM module in order to be able
+ to provide the necessary configuration state.
+ */
+ const p = globalThis.sqlite3ApiBootstrap(bootstrapConfig);
+ delete globalThis.sqlite3ApiBootstrap;
+ return p /* the eventual result of globalThis.sqlite3InitModule() */;
+}catch(e){
+ console.error("sqlite3ApiBootstrap() error:",e);
+ throw e;
+}
+
//console.warn("This is the end of the Module.runSQLite3PostLoadInit handler.");
}/*Module.runSQLite3PostLoadInit(...)*/;
//console.warn("This is the end of the setup of the (pending) Module.runSQLite3PostLoadInit");
Running this function will bootstrap the library and return
a Promise to the sqlite3 namespace object.
*/
-Module.runSQLite3PostLoadInit = function(
+Module.runSQLite3PostLoadInit = async function(
sqlite3InitScriptInfo /* populated by extern-post-js.c-pp.js */,
EmscriptenModule/*the Emscripten-style module object*/,
sqlite3IsUnderTest
- sqlite3-vtab-helper.c-pp.js => Utilities for virtual table impls
- sqlite3-vfs-opfs.c-pp.js => OPFS VFS
- sqlite3-vfs-opfs-sahpool.c-pp.js => OPFS SAHPool VFS
- - sqlite3-api-cleanup.js => final bootstrapping phase
- post-js-footer.js => this file's epilogue
And all of that gets sandwiched between extern-pre-js.js and
const sIMS =
globalThis.sqlite3InitModuleState/*from extern-post-js.c-pp.js*/
|| Object.assign(Object.create(null),{
- debugModule: ()=>{
- console.warn("globalThis.sqlite3InitModuleState is missing");
+ /* In WASMFS builds this file gets loaded once per thread,
+ but sqlite3InitModuleState is not getting set for the
+ worker threads? That those workers seem to function fine
+ despite that is curious. */
+ debugModule: function(){
+ console.warn("globalThis.sqlite3InitModuleState is missing",arguments);
}
});
delete globalThis.sqlite3InitModuleState;
//#endif target:es6-module
}.bind(sIMS);
-//#if Module.instantiateWasm
-//#if not wasmfs
+//#if Module.instantiateWasm and not wasmfs
/**
Override Module.instantiateWasm().
.then(finalThen)
return loadWasm();
}.bind(sIMS);
-//#endif not wasmfs
-//#endif Module.instantiateWasm
+//#endif Module.instantiateWasm and not wasmfs
})(Module);
/* END FILE: api/pre-js.js. */
+++ /dev/null
-/*
- 2022-07-22
-
- The author disclaims copyright to this source code. In place of a
- legal notice, here is a blessing:
-
- * May you do good and not evil.
- * May you find forgiveness for yourself and forgive others.
- * May you share freely, never taking more than you give.
-
- ***********************************************************************
-
- This file is the tail end of the sqlite3-api.js constellation,
- intended to be appended after all other sqlite3-api-*.js files so
- that it can finalize any setup and clean up any global symbols
- temporarily used for setting up the API's various subsystems.
-
- In Emscripten builds it's run in the context of what amounts to a
- Module.postRun handler, though it's no longer actually a postRun
- handler because Emscripten 4.0 changed postRun semantics in an
- incompatible way.
-
- In terms of amalgamation code placement, this file is appended
- immediately after the final sqlite3-api-*.js piece. Those files
- cooperate to prepare sqlite3ApiBootstrap() and this file calls it.
- It is run within a context which gives it access to Emscripten's
- Module object, after sqlite3.wasm is loaded but before
- sqlite3ApiBootstrap() has been called.
-
- Because this code resides (after building) inside the function
- installed by post-js-header.js, it has access to state set up by
- pre-js.c-pp.js and friends.
-*/
-'use strict';
-if( 'undefined' !== typeof EmscriptenModule/*from post-js-header.js*/ ){
- try{
- /* Config options for sqlite3ApiBootstrap(). */
- const bootstrapConfig = Object.assign(
- Object.create(null),
- globalThis.sqlite3ApiBootstrap.defaultConfig, // default options
- globalThis.sqlite3ApiConfig || {}, // optional client-provided options
- /** The WASM-environment-dependent configuration for sqlite3ApiBootstrap() */
- {
- memory: ('undefined'!==typeof wasmMemory)
- ? wasmMemory
- : EmscriptenModule['wasmMemory'],
- exports: ('undefined'!==typeof wasmExports)
- ? wasmExports /* emscripten >=3.1.44 */
- : (Object.prototype.hasOwnProperty.call(EmscriptenModule,'wasmExports')
- ? EmscriptenModule['wasmExports']
- : EmscriptenModule['asm']/* emscripten <=3.1.43 */)
- }
- );
-
- sqlite3InitScriptInfo.debugModule("Bootstrapping lib config", bootstrapConfig);
-
- /**
- For purposes of the Emscripten build, call sqlite3ApiBootstrap().
- Ideally clients should be able to inject their own config here,
- but that's not practical in this particular build constellation
- because of the order everything happens in. Clients may either
- define globalThis.sqlite3ApiConfig or modify
- globalThis.sqlite3ApiBootstrap.defaultConfig to tweak the default
- configuration used by a no-args call to sqlite3ApiBootstrap(),
- but must have first loaded their WASM module in order to be able
- to provide the necessary configuration state.
- */
- const p = globalThis.sqlite3ApiBootstrap(bootstrapConfig);
- delete globalThis.sqlite3ApiBootstrap;
- return p /* the eventual result of globalThis.sqlite3InitModule() */;
- }catch(e){
- console.error("sqlite3ApiBootstrap() error:",e);
- throw e;
- }
-}/*Emscripten post-load lib init*/
sqlite3InitScriptInfo /* from post-js-header.js */;
if( (sqlite3.__isUnderTest = sqlite3IsUnderTest /* from post-js-header.js */) ){
sqlite3.config.emscripten = EmscriptenModule;
+ /*
+ The problem with exposing these pieces (in non-testing runs) via
+ sqlite3.wasm is that it exposes non-SQLite pieces to the
+ clients, who may come to expect it to remain. _We_ only have
+ these data because we've overridden Emscripten's wasm file
+ loader, and if we lose that capability for some reason then
+ we'll lose access to this metadata.
+
+ These data are interesting for exploring how the wasm/JS
+ pieces connect, e.g. for exploring exactly what Emscripten
+ imports into WASM from its JS glue, but it's not
+ SQLite-related.
+ */
const iw = sqlite3InitScriptInfo.instantiateWasm;
if( iw ){
/* Metadata injected by the custom Module.instantiateWasm()
asynchronous Origin-Private FileSystem (OPFS) APIs using a second
Worker, implemented in sqlite3-opfs-async-proxy.js. This file is
intended to be appended to the main sqlite3 JS deliverable somewhere
- after sqlite3-api-oo1.js and before sqlite3-api-cleanup.js.
+ after sqlite3-api-oo1.js.
*/
'use strict';
globalThis.sqlite3ApiBootstrap.initializers.push(function(sqlite3){
-C API\sdoc\stypo\sfix.
-D 2025-11-15T08:05:12.964
+C Move\ssqlite3-api-cleanup.js\sinto\spost-js-footer.js\sto\sremove\sthe\sfinal\sdirect\sEmscripten\sdependency\sfrom\sthe\sintermediary\sbuild\sproduct\ssqlite3-api.js\s(the\swhole\slibrary,\swaiting\sto\sbe\sbootstrapped).\sThis\sis\spartly\sin\sresponse\sto\s[forum:4b7d45433731d2e0|forum\spost\s4b7d45433731d2e0],\swhich\sdemonstrates\sa\spotential\suse\scase\sfor\sa\sstandalone\ssqlite3-api.js.\sThis\sis\sa\sbuild/doc\schange,\snot\sa\sfunctional\sone.
+D 2025-11-15T09:19:03.391
F .fossil-settings/binary-glob 61195414528fb3ea9693577e1980230d78a1f8b0a54c78cf1b9b24d0a409ed6a x
F .fossil-settings/empty-dirs dbb81e8fc0401ac46a1491ab34a7f2c7c0452f2f06b54ebb845d024ca8283ef1
F .fossil-settings/ignore-glob 35175cdfcf539b2318cb04a9901442804be81cd677d8b889fcc9149c21f239ea
F ext/session/sqlite3session.c b3de195ce668cace9b324599bf6255a70290cbfb5451e826e946f3aee6e64c54
F ext/session/sqlite3session.h 7404723606074fcb2afdc6b72c206072cdb2b7d8ba097ca1559174a80bc26f7a
F ext/session/test_session.c 8766b5973a6323934cb51248f621c3dc87ad2a98f023c3cc280d79e7d78d36fb
-F ext/wasm/GNUmakefile b669dac12f134b8ca7e0f2fc49784abe3ae0cf3e559b155d2651c0861ff021f3
+F ext/wasm/GNUmakefile d32546590afc62c7adb71781b929b9fed6b35520e9a17542f576194ab8c9f50c
F ext/wasm/README-dist.txt f01081a850ce38a56706af6b481e3a7878e24e42b314cfcd4b129f0f8427066a
F ext/wasm/README.md 2e87804e12c98f1d194b7a06162a88441d33bb443efcfe00dc6565a780d2f259
F ext/wasm/SQLTester/GNUmakefile e0794f676d55819951bbfae45cc5e8d7818dc460492dc317ce7f0d2eca15caff
F ext/wasm/SQLTester/index.html 64f3435084c7d6139b08d1f2a713828a73f68de2ae6a3112cbb5980d991ba06f
F ext/wasm/SQLTester/touint8array.c 2d5ece04ec1393a6a60c4bf96385bda5e1a10ad49f3038b96460fc5e5aa7e536
F ext/wasm/api/EXPORTED_FUNCTIONS.c-pp d609c22bc05e25991bdd2eeed4497485a3756446158b2794471426e5e3517056
-F ext/wasm/api/README.md df476398c6d80affae807a8208c5a97d1615786e1d6767b5292bfe67edb59b18
+F ext/wasm/api/README.md aae128e14711dafac29e7b645ff1b6be42305b73f74b1303d8401351f8448631
F ext/wasm/api/extern-post-js.c-pp.js 4b310c9891886e7c1ea4e2419966ff45dfeda825b897fdaa4119332509f7e3d1
F ext/wasm/api/extern-pre-js.js cc61c09c7a24a07dbecb4c352453c3985170cec12b4e7e7e7a4d11d43c5c8f41
-F ext/wasm/api/post-js-footer.js 5bd7170b5e8ce7b62102702bbcf47ef7b3b49cd56ed40c043fd990aa715b74ee
-F ext/wasm/api/post-js-header.js 79d078aec33d93b640a19c574b504d88bb2446432f38e2fbb3bb8e36da436e70
-F ext/wasm/api/pre-js.c-pp.js b1a7a09d14df1f36de11e801ba06cb92c0ddeb520e5b2f28836af0ec8146e288
-F ext/wasm/api/sqlite3-api-cleanup.js f0a408704e56d6e59d5c0a2f6d84651b71dc2af39a2a4017256213ee29c65cc4
+F ext/wasm/api/post-js-footer.js ef03962507ee0b5ad0bacd725502aea2e434cc214c666205a9745d2c89eb5c76
+F ext/wasm/api/post-js-header.js ef5b0ddbefba75c2ac92a44856f4e7e05150cea4df24d73282131ac0889e71f6
+F ext/wasm/api/pre-js.c-pp.js ad2546290e0c8ce5ca2081bff6e85cc25eeb904a3303921f1184290a7ff1b32f
F ext/wasm/api/sqlite3-api-glue.c-pp.js 79a54b54ca6324d28e31e19b56bbaebb7d2cc4b3079066e7e901333fa5047c53
F ext/wasm/api/sqlite3-api-oo1.c-pp.js 31dbfd470c91ffd96d77399b749bab6b69e3ba9074188833f97ac13f087cf07b
-F ext/wasm/api/sqlite3-api-prologue.js 68cf99ffc9742462323da3f3b207027472214727a750a952c6c10d53b11a3fa6
+F ext/wasm/api/sqlite3-api-prologue.js a69eba98746c3dfbe54a9b0d653573d69103f47dd3bce7c68be8e5e6766ac2a0
F ext/wasm/api/sqlite3-api-worker1.c-pp.js 1041dd645e8e821c082b628cd8d9acf70c667430f9d45167569633ffc7567938
F ext/wasm/api/sqlite3-license-version-header.js 0c807a421f0187e778dc1078f10d2994b915123c1223fe752b60afdcd1263f89
F ext/wasm/api/sqlite3-opfs-async-proxy.js 9654b565b346dc609b75d15337f20acfa7af7d9d558da1afeb9b6d8eaa404966
F ext/wasm/api/sqlite3-vfs-helper.c-pp.js 3f828cc66758acb40e9c5b4dcfd87fd478a14c8fb7f0630264e6c7fa0e57515d
F ext/wasm/api/sqlite3-vfs-opfs-sahpool.c-pp.js 26cb41d5a62f46a106b6371eb00fef02de3cdbfaa51338ba087a45f53028e0d0
-F ext/wasm/api/sqlite3-vfs-opfs.c-pp.js 418c33fe284739564daab3c7a7a88882fdd3c99137497900f98eddec1e409af5
+F ext/wasm/api/sqlite3-vfs-opfs.c-pp.js af8ab2ac27f503e8255baf377085aeb0aff2f630f9d47f01d1a8a550784ffa9d
F ext/wasm/api/sqlite3-vtab-helper.c-pp.js 9097074724172e31e56ce20ccd7482259cf72a76124213cbc9469d757676da86
F ext/wasm/api/sqlite3-wasm.c 2d1cbe498f7b0fb64b11451eda481f458df74d6258baea635513e637fcbb8b1a
F ext/wasm/api/sqlite3-worker1-promiser.c-pp.js bda1c75bd674a92a0e27cc2f3d46dbbf21e422413f8046814515a0bd7409328a
F tool/warnings-clang.sh bbf6a1e685e534c92ec2bfba5b1745f34fb6f0bc2a362850723a9ee87c1b31a7
F tool/warnings.sh d924598cf2f55a4ecbc2aeb055c10bd5f48114793e7ba25f9585435da29e7e98
F tool/win/sqlite.vsix deb315d026cc8400325c5863eef847784a219a2f
-P fa85534ed927851dc37a4943e83259bff4509f141449226ffb506f9acc7b2cc5
-R 8981135c35a13e0df5d35ec9cdd97af6
+P c1e9791fbf9e4c2ca6f9f031ea2c26d8b4bfb4d54850a53853f2b2d9620792ef
+R bb1eac7c46bbc299ec2a5148cd54f884
U stephan
-Z 52cbb544d51bb9aaa1d3f0d12b50b9ff
+Z b71c372c7945ebd8247fbe33ca972302
# Remove this line to create a well-formed Fossil manifest.
-c1e9791fbf9e4c2ca6f9f031ea2c26d8b4bfb4d54850a53853f2b2d9620792ef
+2fcbd8e17d8f1dd7e9d45168805dba718777e46803d9375a4212296d3d0cd89c
projects / thirdparty / sqlite.git / commitdiff
