database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-12-20 01:22:32 +03:00
Code Activity

Move sqlite3-api-cleanup.js into post-js-footer.js to remove the final direct Emscripten dependency from the intermediary build product sqlite3-api.js (the whole library, waiting to be bootstrapped). This is partly in response to [forum:4b7d45433731d2e0|forum post 4b7d45433731d2e0], which demonstrates a potential use case for a standalone sqlite3-api.js. This is a build/doc change, not a functional one.

Browse Source 
FossilOrigin-Name: 2fcbd8e17d8f1dd7e9d45168805dba718777e46803d9375a4212296d3d0cd89c
This commit is contained in:
stephan
2025-11-15 09:19:03 +00:00
parent 5279cbd353
commit a804a65617
10 changed files with 143 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
ext/wasm/GNUmakefile
View File

@@ -898,7 +898,6 @@ ifeq (0,$(wasm-bare-bones))
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

75
ext/wasm/api/README.md
View File

@@ -60,14 +60,14 @@ maintenance point of view.
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
@@ -77,79 +77,78 @@ by concatenating the following files together in their listed order:
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
@@ -171,23 +170,27 @@ from this file rather than `sqlite3.c`.
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 &uarr; two
&darr; files.)
- **`post-js-footer.js`**\
- **`sqlite3-api.js`** gets sandwiched between these &uarr; two
&darr; 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

68
ext/wasm/api/post-js-footer.js
View File

@@ -1,3 +1,71 @@
/*
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");

3
ext/wasm/api/post-js-header.js
View File

@@ -9,7 +9,7 @@
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
@@ -35,7 +35,6 @@ Module.runSQLite3PostLoadInit = function(
- 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

14
ext/wasm/api/pre-js.c-pp.js
View File

@@ -35,8 +35,12 @@
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;
@@ -89,8 +93,7 @@
//#endif target:es6-module
}.bind(sIMS);
//#if Module.instantiateWasm
//#if not wasmfs
//#if Module.instantiateWasm and not wasmfs
/**
Override Module.instantiateWasm().
@@ -126,7 +129,6 @@
.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. */

75
ext/wasm/api/sqlite3-api-cleanup.js
View File

@@ -1,75 +0,0 @@
/*
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*/

13
ext/wasm/api/sqlite3-api-prologue.js
View File

@@ -2130,6 +2130,19 @@ globalThis.sqlite3ApiBootstrap = async function sqlite3ApiBootstrap(
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()

2
ext/wasm/api/sqlite3-vfs-opfs.c-pp.js
View File

@@ -16,7 +16,7 @@
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){

25
manifest
View File

@@ -1,5 +1,5 @@
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
@@ -575,7 +575,7 @@ F ext/session/sessionwor.test 6fd9a2256442cebde5b2284936ae9e0d54bde692d0f5fd009e
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
@@ -584,22 +584,21 @@ F ext/wasm/SQLTester/SQLTester.run.mjs 57f2adb33f43f2784abbf8026c1bfd049d8013af1
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
@@ -2167,8 +2166,8 @@ F tool/version-info.c 33d0390ef484b3b1cb685d59362be891ea162123cea181cb8e6d2cf6dd
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.

2
manifest.uuid
View File

@@ -1 +1 @@
c1e9791fbf9e4c2ca6f9f031ea2c26d8b4bfb4d54850a53853f2b2d9620792ef
2fcbd8e17d8f1dd7e9d45168805dba718777e46803d9375a4212296d3d0cd89c