####################################################################### # This GNU makefile creates the canonical sqlite3 WASM builds. # # This build assumes a Linux platform and is not intended for # general-purpose client-level use, except for creating builds with # custom configurations. It is primarily intended for the SQLite # project's own development of its JS/WASM components. # # Primary targets: # # default, all = build in dev mode # # o0, o1, o2, o3, os, oz = full clean/rebuild with the -Ox level indicated # by the target name. Rebuild is necessary for all components to get # the desired optimization level. # # dist = create end user deliverables. Add dist.build=oX to build # with a specific optimization level, where oX is one of the # above-listed o? or qo? target names. # # snapshot = like dist, but uses a zip file name which clearly # marks it as a prerelease/snapshot build. # # clean = clean up # # Required tools beyond those needed for the canonical builds: # # - Emscripten SDK: https://emscripten.org/docs/getting_started/downloads.html # - The bash shell # - GNU make, GNU sed, GNU awk, GNU grep (all in the $PATH and without # a "g" prefix like they have on some non-GNU systems) # - wasm-strip for release builds: https://github.com/WebAssembly/wabt # - InfoZip for 'dist' zip file ######################################################################## default: all MAKEFILE = $(lastword $(MAKEFILE_LIST)) CLEAN_FILES = DISTCLEAN_FILES = config.make MAKING_CLEAN = $(if $(filter %clean,$(MAKECMDGOALS)),1,0) # # dir.X = various directory names. # # dir.top = the top dir of the canonical build tree, where # sqlite3.[ch] live. # dir.top = ../.. dir.wasm = $(patsubst %/,%,$(dir $(MAKEFILE))) dir.api = api dir.jacc = jaccwabyt dir.common = common dir.fiddle = fiddle dir.fiddle.debug = fiddle-debug dir.tool = $(dir.top)/tool # dir.dout = output dir for deliverables dir.dout = $(dir.wasm)/jswasm # dir.tmp = output dir for intermediary build files, as opposed to # end-user deliverables. dir.tmp = $(dir.wasm)/bld dir.wasmfs = $(dir.dout) # # Emoji for log messages. # emo.bug = ๐Ÿž emo.compile = โณ emo.roadblock = ๐Ÿšง emo.disk = ๐Ÿ’พ emo.done = โœ… emo.fire = ๐Ÿ”ฅ emo.folder = ๐Ÿ“ emo.garbage = ๐Ÿ—‘ emo.lock = ๐Ÿ”’ emo.magic = ๐Ÿง™ emo.megaphone = ๐Ÿ“ฃ emo.mute = ๐Ÿ”‡ emo.edit = โœ๏ธ emo.stop = ๐Ÿ›‘ emo.strip = ๐Ÿ’ˆ emo.test = ๐Ÿงช emo.tool = ๐Ÿ”จ emo.wasm-opt = ๐Ÿงผ # ๐Ÿ‘ท๐Ÿช„๐Ÿงฎ๐Ÿงซ๐Ÿงฝ๐Ÿฟโ›ฝ๐Ÿšง๐ŸŽฑ๐Ÿชš๐Ÿ†๐Ÿงผ # # Special-case builds for which we require certain pre-conditions # which, if not met, may cause warnings or fatal errors in the build. # This also affects the default optimization level flags. The fiddle # targets are in this list because they are used for generating # sqlite.org/fiddle. # OPTIMIZED_TARGETS = dist snapshot fiddle fiddle.debug ifeq (1,$(MAKING_CLEAN)) bin.wasm-strip = echo "not stripping" bin.wasm-opt = irrelevant bin.emcc = irrelevant bin.bash = irrelevant emcc.version = unknown else # Include config.make and perform some bootstrapping... ifeq (,$(wildcard ./config.make)) $(error Missing config.make. It gets generated by the configure script if the EMSDK is found) endif include ./config.make ifeq (,$(bin.bash)) $(error Configure script did not find the bash shell) endif ifeq (,$(bin.emcc)) $(error Configure script did not find emcc) endif emcc.version = $(shell $(bin.emcc) --version | sed -n 1p | sed -e 's/^.* \([3-9][^ ]*\) .*$$/\1/;') $(info using emcc version [$(emcc.version)]) ifeq (,$(bin.wasm-strip)) # # We need wasm-strip for release builds (see below for why) but # not strictly for non-release builds. # achtung = $(emo.fire)WARNING $(info $(achtung): *******************************************************************) $(info $(achtung): Builds using -Oz will minify WASM-exported names, breaking) $(info $(achtung): _All The Things_. The workaround for that is to build) $(info $(achtung): with -g3 (which explodes the file size) and then strip the debug) $(info $(achtung): info after compilation, using wasm-strip, to shrink the wasm file.) $(info $(achtung): wasm-strip was not found in the PATH so we cannot strip those.) $(info $(achtung): If this build uses any optimization level higher than -O1 then) $(info $(achtung): the ***resulting JS code WILL NOT BE USABLE***.) $(info $(achtung): wasm-strip is part of the wabt package:) $(info $(achtung): https://github.com/WebAssembly/wabt) $(info $(achtung): on Ubuntu-like systems it can be installed with:) $(info $(achtung): sudo apt install wabt) $(info $(achtung): *******************************************************************) ifneq (,$(filter $(OPTIMIZED_TARGETS),$(MAKECMDGOALS))) $(error Cannot make release-quality binary because wasm-strip is not available.) endif bin.wasm-strip = echo "not wasm-stripping" endif ifeq (,$(filter $(OPTIMIZED_TARGETS),$(MAKECMDGOALS))) $(info ==============================================================) $(info == Development build. Make one of (dist, snapshot) for a) $(info == smaller and faster release build.) $(info ==============================================================) endif endif # ^^^ end of are-we-MAKING_CLEAN # # Common vars and $(call)/$(eval)able utilities. # # The "b." prefix on some APIs is for "build". It was initially used # only for features specific to each distinct js/wasm build. That's no # longer the case, but the naming convention has stuck. # loud ?= 0 ifeq (1,$(loud)) $(info $(emo.megaphone) Emitting loud build info. Pass loud=0 to disable it.) b.cmd@ = loud.if = 1 else $(info $(emo.mute) Eliding loud build info. Pass loud=1 to enable it.) b.cmd@ = @ loud.if = endif # # logtag.X value for log context labeling. logtag.OTHERX can be # assigned to customize it for a given X. This tag is used by # b.call.X, b.eval.X, etc. for logging. There motivation for this is # adding a build-specific prefix to messages so that the output of # parallel builds is easier to sort through. We use emoji for the # prefixes because it's far easier for my eyes to sort through than # using only each build's name as the prefix. # # Each distinct build sets up its own logtag.BUILDNAME. # logtag.@ = [$@] logtag.filter = [$(emo.disk) $@] logtag.test = [$(emo.test) $@] logtag.cp = [$(emo.disk) $@] # # $(call b.echo,LOGTAG,msg) # b.echo = echo $(logtag.$(1)) $(2) # # $(call b.mkdir@) # # $1 = optional LOGTAG # b.mkdir@ = if [ ! -d $(dir $@) ]; then \ echo '[$(emo.folder)+] $(if $(1),$(logtag.$(1)),[$(dir $@)])'; \ mkdir -p $(dir $@) || exit; fi # # $(call b.cp,@,src,dest) # # $1 = logtag, $2 = src file(s). $3 = dest dir b.cp = $(call b.mkdir@); \ echo '$(logtag.$(1)) $(emo.disk) $(2) ==> $3'; \ cp -p $(2) $(3) || exit # # $(call b.c-pp.shcmd,LOGTAG,src,dest,-Dx=y...) # # Resolves to shell code to create $(3) from $(2) and $(4) using # $(bin.c-pp). # # $1 = build name/logtag # $2 = Input file(s) # $3 = Output file # $4 = optional $(bin.c-pp) flags define b.c-pp.shcmd $(call b.mkdir@); \ $(call b.echo,$(1),$(emo.disk)$(emo.lock) $(bin.c-pp) $(4) $(if $(loud.if),$(2))); \ rm -f $(3); \ $(bin.c-pp) -o $(3) $(4) $(2) || exit; \ chmod -w $(3) endef # # $(eval $(call b.c-pp.target,LOGTAG,src,dest,-Dx=y...)) # # Creates target $(3) using $(bin.c-pp) $(2) $(4). # # Args: as for $(b.c-pp.shcmd). define b.c-pp.target $(3): $$(MAKEFILE_LIST) $$(bin.c-pp) $(2) @$$(call b.c-pp.shcmd,$(1),$(2),$(3),$(4)) CLEAN_FILES += $(3) endef c-pp.D.64bit = -Dbits64 # # $(call b.strip-js-emcc-bindings) # # $1 = an optional log message prefix # # Our JS code installs bindings of each sqlite3_...() WASM export. The # generated Emscripten JS file does the same using its own framework, # but we don't use those results and can speed up lib init, and reduce # memory cost a bit, by stripping them out. Emscripten code-generation # changes can "break" this, causing this to be a no-op, but (probably) # the worst that can happen in that case is that it doesn't actually # strip anything, leading to slightly larger JS files. # # This is intended to be used in makefile targets which generate an # Emscripten module and where $@ is the module's .js/.mjs file. b.strip-js-emcc-bindings = \ sed -i -e '/^.*= \(_sqlite3\|_fiddle\)[^=]*=.*createExportWrapper/d' \ -e '/^var \(_sqlite3\|_fiddle\)[^=]*=.*makeInvalidEarlyAccess/d' $@ || exit; \ echo '$(1) $(emo.garbage) (Probably) /createExportWrapper()/d and /makeInvalidEarlyAccess()/d' # # bin.version-info = binary to output various sqlite3 version info for # embedding in the JS files and in building the distribution zip file. # It must NOT be in $(dir.tmp) because we need it to survive the # cleanup process for the dist build to work properly. # # Slight caveat: this uses the version info from the in-tree # sqlite3.c/h, which may diff from a user-provided $(sqlite3.c). The # end result is that the generated JS files may have static version # info from $(bin.version-info) which differ from their runtime-emitted # version info (e.g. from sqlite3_libversion()). bin.version-info = $(dir.top)/version-info $(bin.version-info): $(dir.tool)/version-info.c $(sqlite3.h) $(dir.top)/Makefile $(MAKE) -C $(dir.top) version-info t-version-info: $(bin.version-info) # # bin.stripcomments is used for stripping C/C++-style comments from JS # files. The JS files contain large chunks of documentation which we # don't need for all builds. That app's -k flag is of particular # importance here, as it allows us to retain the opening comment # block(s), which contain the license header and version info. bin.stripccomments = $(dir.tool)/stripccomments $(bin.stripccomments): $(bin.stripccomments).c $(MAKEFILE) $(CC) -o $@ $< t-stripccomments: $(bin.stripccomments) DISTCLEAN_FILES += $(bin.stripccomments) # # Set up sqlite3.c and sqlite3.h... # # To build with SEE (https://sqlite.org/see), either put sqlite3-see.c # in $(dir.top) or pass sqlite3.c=PATH_TO_sqlite3-see.c to the $(MAKE) # invocation. Note that only encryption modules with no 3rd-party # dependencies will currently work here: AES256-OFB, AES128-OFB, and # AES128-CCM. Not coincidentally, those 3 modules are included in the # sqlite3-see.c bundle. Note, however, that distributing an SEE build # of the WASM on a public site is in violation of the SEE license # because it effectively provides a usable copy of the SEE build to # all visitors. # # A custom sqlite3.c must not have any spaces in its name. # $(sqlite3.canonical.c) must point to the sqlite3.c in # the sqlite3 canonical source tree, as that source file # is required for certain utility and test code. sqlite3.canonical.c = $(dir.top)/sqlite3.c sqlite3.c ?= $(firstword $(wildcard $(dir.top)/sqlite3-see.c) $(sqlite3.canonical.c)) sqlite3.h = $(dir.top)/sqlite3.h ifeq (1,$(MAKING_CLEAN)) SQLITE_C_IS_SEE = 0 else ifeq (,$(shell grep sqlite3_activate_see $(sqlite3.c))) SQLITE_C_IS_SEE = 0 else SQLITE_C_IS_SEE = 1 $(info This is an SEE build) endif endif # # barebones=1 disables all "extraneous" stuff from sqlite3-wasm.c, the # goal being to create a WASM file with only the core APIs. # ifeq (1,$(barebones)) wasm-bare-bones = 1 $(info ==============================================================) $(info == This is a bare-bones build. It trades away features for) $(info == a smaller .wasm file.) $(info ==============================================================) else wasm-bare-bones = 0 endif # undefine barebones # relatively new gmake feature, not ubiquitous # # It's important that sqlite3.h be built to completion before any # other parts of the build run, thus we use .NOTPARALLEL to disable # parallel build of that file and its dependants. However, that makes # the whole build non-parallelizable because everything has a dep on # sqlite3.h/c. The alternative is to force the user to run (make # sqlite3.c) from the top of the tree before running this build. # #.NOTPARALLEL: $(sqlite3.h) # $(sqlite3.h): @echo "$(sqlite3.h) is out of date. "; \ echo "To avoid problems with parallel builds, we're exiting now. Please do:"; \ echo " $(MAKE) -C $(dir.top) sqlite3.c"; \ echo "and try again."; exit 1 # $(MAKE) -C $(dir.top) sqlite3.c $(sqlite3.c): $(sqlite3.h) # Common options for building sqlite3-wasm.c and speedtest1.c. # Explicit ENABLEs... SQLITE_OPT.common = \ -DSQLITE_THREADSAFE=0 \ -DSQLITE_TEMP_STORE=2 \ -DSQLITE_ENABLE_MATH_FUNCTIONS \ -DSQLITE_OS_KV_OPTIONAL=1 \ '-DSQLITE_DEFAULT_UNIX_VFS="unix-none"' \ -DSQLITE_USE_URI=1 \ -DSQLITE_C=$(sqlite3.c) \ -DSQLITE_OMIT_DEPRECATED \ -DSQLITE_OMIT_UTF16 \ -DSQLITE_OMIT_LOAD_EXTENSION \ -DSQLITE_OMIT_SHARED_CACHE # ^^^ These particular OMITs are hard-coded in sqlite3-wasm.c and # removing them from this list will serve only to break the speedtest1 # builds. # Currently always needed but TODO is paring tester1.c-pp.js down # to be able to run without this: SQLITE_OPT.common += -DSQLITE_WASM_ENABLE_C_TESTS # Extra flags for full-featured builds... SQLITE_OPT.full-featured = \ -DSQLITE_ENABLE_BYTECODE_VTAB \ -DSQLITE_ENABLE_DBPAGE_VTAB \ -DSQLITE_ENABLE_DBSTAT_VTAB \ -DSQLITE_ENABLE_FTS5 \ -DSQLITE_ENABLE_MATH_FUNCTIONS \ -DSQLITE_ENABLE_OFFSET_SQL_FUNC \ -DSQLITE_ENABLE_PREUPDATE_HOOK \ -DSQLITE_ENABLE_RTREE \ -DSQLITE_ENABLE_SESSION \ -DSQLITE_ENABLE_STMTVTAB \ -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION \ -DSQLITE_ENABLE_COLUMN_METADATA \ -DSQLITE_ENABLE_PERCENTILE=1 ifeq (0,$(wasm-bare-bones)) # The so-called canonical build is full-featured: SQLITE_OPT = \ $(SQLITE_OPT.common) \ $(SQLITE_OPT.full-featured) else # The so-called bare-bones build is exactly that: SQLITE_OPT = \ $(SQLITE_OPT.common) \ -DSQLITE_WASM_BARE_BONES # SQLITE_WASM_BARE_BONES tells sqlite3-wasm.c to explicitly omit # a bunch of stuff, in the interest of keeping the wasm file size # down. As of this writing it equates to: # # -USQLITE_ENABLE_DBPAGE_VTAB # -USQLITE_ENABLE_DBSTAT_VTAB # -USQLITE_ENABLE_EXPLAIN_COMMENTS # -USQLITE_ENABLE_FTS5 # -USQLITE_ENABLE_OFFSET_SQL_FUNC # -USQLITE_ENABLE_PREUPDATE_HOOK # -USQLITE_ENABLE_RTREE # -USQLITE_ENABLE_SESSION # -USQLITE_ENABLE_STMTVTAB # -DSQLITE_OMIT_AUTHORIZATION # -DSQLITE_OMIT_GET_TABLE # -DSQLITE_OMIT_INCRBLOB # -DSQLITE_OMIT_INTROSPECTION_PRAGMAS # -DSQLITE_OMIT_JSON # -DSQLITE_OMIT_PROGRESS_CALLBACK # -DSQLITE_OMIT_WAL # # There are others we want here but which require explicit OMIT when # creating their amalgamation, and that step is TODO: # # -DSQLITE_OMIT_EXPLAIN # -DSQLITE_OMIT_TRIGGER # -DSQLITE_OMIT_VIRTUALTABLE # -DSQLITE_OMIT_WINDOWFUNC endif #SQLITE_OPT += -DSQLITE_DEBUG # Enabling SQLITE_DEBUG will break sqlite3_wasm_vfs_create_file() # (and thus sqlite3_js_vfs_create_file()). Those functions are # deprecated and alternatives are in place, but this crash behavior # can be used to find errant uses of sqlite3_js_vfs_create_file() # in client code. ######################################################################## # The following flags are hard-coded into sqlite3-wasm.c and cannot be # modified via the build process: # # SQLITE_ENABLE_API_ARMOR # SQLITE_OMIT_LOAD_EXTENSION # SQLITE_OMIT_DEPRECATED # SQLITE_OMIT_UTF16 # SQLITE_OMIT_SHARED_CACHE ######################################################################## ######################################################################## # Adding custom C code via sqlite3_wasm_extra_init.c: # # If the canonical build process finds the file # sqlite3_wasm_extra_init.c in the main wasm build directory, it # arranges to include that file in the build of sqlite3.wasm and # defines SQLITE_EXTRA_INIT_MUTEXED=sqlite3_wasm_extra_init. # # sqlite3_wasm_extra_init() must be a function with this signature: # # int sqlite3_wasm_extra_init(const char *) # # and the sqlite3 library will call it with an argument of NULL one # time during sqlite3_initialize(). If it returns non-0, # initialization of the library will fail. # # The filename can be overridden with: # # make sqlite3_wasm_extra_init.c=my_custom_stuff.c # # See example_extra_init.c for an example implementation. ######################################################################## sqlite3_wasm_extra_init.c ?= $(wildcard sqlite3_wasm_extra_init.c) cflags.wasm_extra_init = ifneq (,$(sqlite3_wasm_extra_init.c)) $(info Enabling SQLITE_EXTRA_INIT via $(sqlite3_wasm_extra_init.c).) cflags.wasm_extra_init = -DSQLITE_WASM_EXTRA_INIT endif # # Actitivates (or not) a custom Module.instantiateWasm() override for # Emscripten. That override gives us more control over exactly which # WASM file is in use. # # If $(WASM_CUSTOM_INSTANTIATE) is 1 then mkwasmbuilds will add # -Dcustom-Module.instantiateWasm to some of the builds. This is # experimental but works on all browsers tested by its developer. # # Changing this may require a clean rebuild. It also might not work. # WASM_CUSTOM_INSTANTIATE = 1 ######################################################################## # $(bin.c-pp): a minimal text file preprocessor. Like C's but much # less so. # # Historical notes about preprocessing files in this project: # # - We first attempted to use gcc and/or clang to preprocess JS files # in the same way we would normally do C files, but C-specific quirks # of each makes that untennable. # # - We implemented c-pp-lite.c (the C-Minus Pre-processor) as a custom # generic/file-format-agnostic preprocessor to enable us to pack # code for different target builds into the same JS files. Most # notably, some ES6 module (a.k.a. ESM) features cannot legally be # referenced at all in non-ESM code, e.g. the "import" and "export" # keywords. This preprocessing step permits us to swap out sections # of code where necessary for ESM and non-ESM (a.k.a. vanilla JS) # require different implementations. The alternative to such # preprocessing, would be to have separate source files for ES6 # builds, which would have a higher maintenance burden than # c-pp-lite.c seems likely to. # # c-pp-lite.c was written specifically for the sqlite project's # JavaScript builds but is maintained as a standalone project: # https://fossil.wanderinghorse.net/r/c-pp # # The SQLITE_... build flags used here have NO EFFECT on the JS/WASM # build. They are solely for use with $(bin.c-pp) itself. # # -D... flags which should be included in all invocations should be # appended to $(b.c-pp.target.flags). bin.c-pp = ./c-pp-lite $(bin.c-pp): c-pp-lite.c $(sqlite3.c) $(MAKEFILE) $(CC) -O0 -o $@ c-pp-lite.c $(sqlite3.c) '-DCMPP_DEFAULT_DELIM="//#"' -I$(dir.top) \ -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_DEPRECATED -DSQLITE_OMIT_UTF16 \ -DSQLITE_OMIT_SHARED_CACHE -DSQLITE_OMIT_WAL -DSQLITE_THREADSAFE=0 \ -DSQLITE_TEMP_STORE=3 DISTCLEAN_FILES += $(bin.c-pp) b.c-pp.target.flags ?= ifeq (1,$(SQLITE_C_IS_SEE)) b.c-pp.target.flags += -Denable-see endif # cflags.common = C compiler flags for all builds cflags.common = -I. -I$(dir $(sqlite3.c)) -std=c99 -fPIC # emcc.WASM_BIGINT = 1 for BigInt (C int64) support, else 0. The API # disables certain features if BigInt is not enabled and such builds # _are not tested_ on any regular basis. emcc.WASM_BIGINT ?= 1 emcc.MEMORY64 ?= 0 ######################################################################## # https://emscripten.org/docs/tools_reference/settings_reference.html#memory64 # # 64-bit build requires wasm-strip 1.0.36 (maybe 1.0.35, but not # 1.0.34) or will fail to strip with "tables may not be 64-bit". ######################################################################## # emcc_opt = optimization-related flags. These are primarily used by # the various oX targets. build times for -O levels higher than 0 are # painful at dev-time. # # When running any of the $(OPTIMIZED_TARGETS) explicitly, e.g. for a # release distribution, use a higher optimization level. Experience # has shown -Oz to produce the smallest deliverables with only a # roughly 10% performance hit in the resulting WASM file compared to # -O2 (which consistently creates the fastest-running deliverables). # Build time suffers greatly compared to -O0, which is why -O0 is the # default. ifeq (,$(filter $(OPTIMIZED_TARGETS),$(MAKECMDGOALS))) emcc_opt ?= -O0 else emcc_opt ?= -Oz endif # When passing emcc_opt from the CLI, += and re-assignment have no # effect, so emcc_opt+=-g3 doesn't work. So... emcc_opt_full = $(emcc_opt) -g3 # ^^^ ALWAYS use -g3. See below for why. # # ^^^ -flto improves runtime speed at -O0 considerably but doubles # build time. # # ^^^^ (-O3, -Oz, -Os) all minify symbol names and there appears to be # no way around that except to use -g3, but -g3 causes the binary file # size to absolutely explode (approx. 5x larger). This minification # utterly breaks the resulting module, making it unsable except as # self-contained/self-referential-only code, as ALL of the exported # symbols get minified names. # # However, we have an option for using -Oz or -Os: # # Build with (-Os -g3) or (-Oz -g3) then use wasm-strip, from the wabt # tools package (https://github.com/WebAssembly/wabt), to strip the # debugging symbols. That results in a small build with unmangled # symbol names. -Oz gives ever-so-slightly better compression than # -Os: not quite 1% in some completely unscientific tests. Runtime # speed for the unit tests is all over the place either way so it's # difficult to say whether -Os gives any speed benefit over -Oz. # # Much practice has demonstrated that -O2 consistently gives the best # runtime speeds, but not by a large enough factor to rule out use of # -Oz when smaller deliverable size is a priority. ######################################################################## ######################################################################## # EXPORTED_FUNCTIONS.* = files for use with Emscripten's # -sEXPORTED_FUNCTION flag. EXPORTED_FUNCTIONS.api.core = $(dir.api)/EXPORTED_FUNCTIONS.sqlite3-core EXPORTED_FUNCTIONS.api.in = $(EXPORTED_FUNCTIONS.api.core) ifeq (1,$(SQLITE_C_IS_SEE)) EXPORTED_FUNCTIONS.api.in += $(dir.api)/EXPORTED_FUNCTIONS.sqlite3-see endif ifeq (0,$(wasm-bare-bones)) EXPORTED_FUNCTIONS.api.in += $(dir.api)/EXPORTED_FUNCTIONS.sqlite3-extras endif EXPORTED_FUNCTIONS.api = $(dir.tmp)/EXPORTED_FUNCTIONS.api $(EXPORTED_FUNCTIONS.api): $(EXPORTED_FUNCTIONS.api.in) $(sqlite3.c) $(MAKEFILE) @$(call b.mkdir@) cat $(EXPORTED_FUNCTIONS.api.in) > $@ ######################################################################## # emcc flags for .c/.o/.wasm/.js. emcc.flags = ifeq (1,$(emcc.verbose)) emcc.flags += -v # -v is _very_ loud but also informative about what it's doing endif # # emcc flags for .c/.o. # emcc.cflags = emcc.cflags += -std=c99 -fPIC # -------------^^^^^^^^ we need c99 for $(sqlite3-wasm.c), primarily # for variadic macros and snprintf() to implement # sqlite3__wasm_enum_json(). emcc.cflags += -I. -I$(dir.top) # # emcc flags specific to building .js/.wasm files... # emcc.jsflags = -fPIC #emcc.jsflags += -Wno-gcc-install-dir-libstdcxx #emcc is not passing ^^^ this on to clang emcc.jsflags += --no-entry emcc.jsflags += -sWASM_BIGINT=$(emcc.WASM_BIGINT) emcc.jsflags += -sMODULARIZE emcc.jsflags += -sDYNAMIC_EXECUTION=0 emcc.jsflags += -sNO_POLYFILL emcc.jsflags += -sEXPORTED_FUNCTIONS=@$(EXPORTED_FUNCTIONS.api) emcc.exportedRuntimeMethods = \ -sEXPORTED_RUNTIME_METHODS=wasmMemory # wasmMemory ==> required by our code for use with -sIMPORTED_MEMORY # Emscripten 4.0.7 (2025-04-15) stops exporting HEAP* by default. emcc.jsflags += $(emcc.exportedRuntimeMethods) emcc.jsflags += -sUSE_CLOSURE_COMPILER=0 emcc.jsflags += -sIMPORTED_MEMORY ifeq (,$(filter -O0,$(emcc_opt))) emcc.assert ?= 0 else emcc.assert ?= 2 endif emcc.jsflags += -sASSERTIONS=$(emcc.assert) emcc.jsflags += -sSTRICT_JS=0 # STRICT_JS disabled due to: # https://github.com/emscripten-core/emscripten/issues/18610 # TL;DR: does not work with MODULARIZE or EXPORT_ES6 as of version # 3.1.31. The fix for that in newer emcc's is to throw a built-time # error if STRICT_JS is used together with those options. # emcc.jsflags += -sSTRICT=1 # -sSTRICT=1 Causes failures about unknown symbols which the build # tools should be installing, e.g. __syscall_geteuid32 # # -sINITIAL_MEMORY: How much memory we need to start with is governed # at least in part by whether -sALLOW_MEMORY_GROWTH is enabled. If so, # we can start with less. If not, we need as much as we'll ever # possibly use (which, of course, we can't know for sure). speedtest1 # shows that performance for even moderate workloads MAY suffer # considerably if we start small and have to grow at runtime. # e.g. OPFS-backed (speedtest1 --size 75) take MAY take X time with # 16mb+ memory and 3X time when starting with 8MB. However, such test # results are inconsistent due to browser internals which are opaque # to us. # # 2024-03-04: emsdk 3.1.55 replaces INITIAL_MEMORY with INITIAL_HEAP, # but also says (in its changelog): "Note that it is currently not # supported in all configurations (#21071)." # https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md # # 2025-09-25: it turns out that _this_ WASM's heap size is not # affected by Emscripten's in-memory virtual filesystem, so we don't # strictly need a lot of heap. Resizing the heap is slow, though, so # we want to start off with some room to grow. # emcc.jsflags += -sALLOW_MEMORY_GROWTH emcc.INITIAL_MEMORY.128 = 134217728 emcc.INITIAL_MEMORY.96 = 100663296 emcc.INITIAL_MEMORY.64 = 67108864 emcc.INITIAL_MEMORY.32 = 33554432 emcc.INITIAL_MEMORY.16 = 16777216 emcc.INITIAL_MEMORY.8 = 8388608 emcc.INITIAL_MEMORY.4 = 4194304 emcc.INITIAL_MEMORY ?= 8 ifeq (,$(emcc.INITIAL_MEMORY.$(emcc.INITIAL_MEMORY))) $(error emcc.INITIAL_MEMORY must be one of: 4, 8, 16, 32, 64, 96, 128 (megabytes)) endif emcc.jsflags += -sINITIAL_MEMORY=$(emcc.INITIAL_MEMORY.$(emcc.INITIAL_MEMORY)) # /INITIAL_MEMORY ######################################################################## #emcc.jsflags += -sMEMORY64=$(emcc.MEMORY64) emcc.jsflags += $(emcc.environment) emcc.jsflags += -sSTACK_SIZE=512KB # ^^^ ACHTUNG: emsdk 3.1.27 reduced the default stack size from 5MB to # a mere 64KB, which leads to silent memory corruption via the kvvfs # VFS, which requires twice that for its xRead() and xWrite() methods. # 2023-03: those methods have since been adapted to use a malloc()'d # buffer. ######################################################################## # $(sqlite3.js.init-func) is the name Emscripten assigns our exported # module init/load function. This symbol name is hard-coded in # $(extern-post-js.js) as well as in numerous docs. # # "sqlite3InitModule" is the symbol we document for client use, so # that's the symbol name which must be exported, whether it comes from # Emscripten or our own code in extern-post-js.js. # # That said... we can change $(sqlite3.js.init-func) as long as the # name "sqlite3InitModule" is the one which gets exposed via the # resulting JS files. That can be accomplished via # extern-post-js.js. However... using a temporary symbol name here # and then adding sqlite3InitModule() ourselves results in 2 global # symbols: we cannot "delete" the Emscripten-defined # $(sqlite3.js.init-func) from vanilla builds (as opposed to ESM # builds) because it's declared with "var". sqlite3.js.init-func = sqlite3InitModule emcc.jsflags += -sEXPORT_NAME=$(sqlite3.js.init-func) emcc.jsflags += -sGLOBAL_BASE=4096 # HYPOTHETICALLY keep func table indexes from overlapping w/ heap addr. #emcc.jsflags += -sSTRICT # fails due to missing __syscall_...() #emcc.jsflags += -sALLOW_UNIMPLEMENTED_SYSCALLS #emcc.jsflags += -sFILESYSTEM=0 # only for experimentation. fiddle needs the FS API #emcc.jsflags += -sABORTING_MALLOC # only for experimentation emcc.jsflags += -sALLOW_TABLE_GROWTH # ^^^^ -sALLOW_TABLE_GROWTH is required for installing new SQL UDFs emcc.jsflags += -Wno-limited-postlink-optimizations # ^^^^ emcc likes to warn when we have "limited optimizations" via the # -g3 flag. # emcc.jsflags += -sSTANDALONE_WASM # causes OOM errors, not sure why. # Re. undefined symbol handling, see: https://lld.llvm.org/WebAssembly.html emcc.jsflags += -sERROR_ON_UNDEFINED_SYMBOLS=1 emcc.jsflags += -sLLD_REPORT_UNDEFINED #emcc.jsflags += --allow-undefined #emcc.jsflags += --import-undefined #emcc.jsflags += --unresolved-symbols=import-dynamic --experimental-pic #emcc.jsflags += --experimental-pic --unresolved-symbols=ingore-all --import-undefined #emcc.jsflags += --unresolved-symbols=ignore-all ######################################################################## # -sSINGLE_FILE: # https://github.com/emscripten-core/emscripten/blob/main/src/settings.js # # -sSINGLE_FILE=1 would be _really_ nice but we have to build with -g3 # for -O2 and higher to work (else minification breaks the code) and # cannot wasm-strip the binary before it gets encoded into the JS # file. The result is that the generated JS file is, because of the # -g3 debugging info, _huge_. ######################################################################## sqlite3.wasm = $(dir.dout)/sqlite3.wasm sqlite3-wasm.c = $(dir.api)/sqlite3-wasm.c sqlite3-wasm.c.in = $(sqlite3-wasm.c) $(sqlite3_wasm_extra_init.c) # # b.call.patch-export-default is used by mkwasmbuilds.c and the # wasmfs build. $1 is 1 if the build mode needs this workaround # (modes: esm, bundler-friendly, node) and 0 if not (vanilla). $2 must # be 0 for all builds except sqlite3-wasmfs.mjs, in which case it must # be 1. $(3) is an optional log prefix, defaulting to $(logtag.@) # # Reminder for ESM builds: even if we use -sEXPORT_ES6=0, emcc _still_ # adds: # # export default $(sqlite3.js.init-func); # # when building *.mjs, which is bad because we need to export an # overwritten version of that function and cannot "export default" # twice. Because of this, we have to sed *.mjs to remove the _first_ # instance (only) of /^export default/. # # Upstream RFE: # https://github.com/emscripten-core/emscripten/issues/18237 # # Maintenance reminder: Mac sed works differently than GNU sed, so we # use awk instead of sed for this. # define b.call.patch-export-default if [ x1 = x$(1) ]; then \ echo "$(if $(3),$(3),$(logtag.@)) $(emo.bug) Fragile" \ "workaround for emscripten/issues/18237." \ "See b.call.patch-export-default."; \ {\ awk '/^export default/ && !f{f=1; next} 1' $@ \ > $@.tmp && mv $@.tmp $@; \ } || exit; \ if [ x1 = x$(2) ]; then \ if ! grep -q '^export default' $@; then \ echo "Cannot find export default." 1>&2; \ exit 1; \ fi; \ fi; \ fi endef # # The various -D... values used by *.c-pp.js include: # # -Dtarget:es6-module: for all ESM module builds # # -Dtarget:node: for node.js builds # # -Dtarget:es6-module -Dtarget:es6-bundler-friendly: intended for # "bundler-friendly" ESM module build. These have some restrictions # on how URL() objects are constructed in some contexts: URLs which # refer to files which are part of this project must be referenced # as string literals so that bundlers' static-analysis tools can # find those files and include them in their bundles. # # -Dtarget:es6-module -Dtarget:node: is intended for use by node.js # for node.js, as opposed to by node.js on behalf of a # browser. Mixing -sENVIRONMENT=web and -sENVIRONMENT=node leads to # ambiguity and confusion on node's part, as it's unable to # reliably determine whether the target is a browser or node. # # To repeat: all node.js builds are 100% untested and unsupported. # ######################################################################## # # Inputs/outputs for the sqlite3-api.js family. # # sqlite3-api.jses = the list of JS files which make up # sqlite3-api.js, in the order they need to be assembled. sqlite3-api.jses = $(sqlite3-license-version.js) sqlite3-api.jses += $(dir.api)/sqlite3-api-prologue.js sqlite3-api.jses += $(dir.common)/whwasmutil.js sqlite3-api.jses += $(dir.jacc)/jaccwabyt.js sqlite3-api.jses += $(dir.api)/sqlite3-api-glue.c-pp.js sqlite3-api.jses += $(sqlite3-api-build-version.js) sqlite3-api.jses += $(dir.api)/sqlite3-api-oo1.c-pp.js sqlite3-api.jses += $(dir.api)/sqlite3-api-worker1.c-pp.js sqlite3-api.jses += $(dir.api)/sqlite3-vfs-helper.c-pp.js ifeq (0,$(wasm-bare-bones)) sqlite3-api.jses += $(dir.api)/sqlite3-vtab-helper.c-pp.js 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 # # $(sqlite3-license-version.js) contains the license header and # in-comment build version info. # # Maintenance reminder: there are awk binaries out there which do not # support -e SCRIPT. # sqlite3-license-version.js = $(dir.tmp)/sqlite3-license-version.js $(sqlite3-license-version.js): $(bin.version-info) \ $(dir.api)/sqlite3-license-version-header.js @echo '$(logtag.@) $(emo.disk)'; { \ $(call b.mkdir@); \ cat $(dir.api)/sqlite3-license-version-header.js || exit $$?; \ echo '/*'; \ echo '** This code was built from sqlite3 version...'; \ echo '**'; \ awk '/define SQLITE_VERSION/{$$1=""; print "**" $$0}' $(sqlite3.h); \ awk '/define SQLITE_SOURCE_ID/{$$1=""; print "**" $$0}' $(sqlite3.h); \ echo '**'; echo '** Emscripten SDK: $(emcc.version)'; \ echo '**'; \ echo '*/'; \ } > $@ # # $(sqlite3-api-build-version.js) injects the build version info into # the bundle in JSON form. # sqlite3-api-build-version.js = $(dir.tmp)/sqlite3-api-build-version.js $(sqlite3-api-build-version.js): $(bin.version-info) $(MAKEFILE) @echo '$(logtag.@) $(emo.disk)'; { \ $(call b.mkdir@); \ echo 'globalThis.sqlite3ApiBootstrap.initializers.push(function(sqlite3){'; \ echo -n ' sqlite3.version = '; \ $(bin.version-info) --json; \ echo ';'; \ echo '});'; \ } > $@ # # extern-post-js* and extern-pre-js* are files for use with # Emscripten's --extern-pre-js and --extern-post-js flags. # extern-pre-js.js = $(dir.api)/extern-pre-js.js extern-post-js.in.js = $(dir.api)/extern-post-js.c-pp.js # # Emscripten flags for --[extern-][pre|post]-js=... for the # various builds. # pre-post-jses.*.deps = lists of dependencies for the # --[extern-][pre/post]-js files. # pre-post-jses.common.deps = $(extern-pre-js.js) $(sqlite3-license-version.js) # --post-js and --pre-js are emcc flags we use to append/prepend JS to # the generated emscripten module file. These rules set up the core # pre/post files for use by the various builds. --pre-js is used to # inject code which needs to run as part of the pre-WASM-load phase. # --post-js injects code which runs after the WASM module is loaded # and includes the entirety of the library plus some # Emscripten-specific post-bootstrapping code. pre-js.in.js = $(dir.api)/pre-js.c-pp.js post-js.in.js = $(dir.tmp)/post-js.c-pp.js post-jses.js = \ $(dir.api)/post-js-header.js \ $(sqlite3-api.jses) \ $(dir.api)/post-js-footer.js $(post-js.in.js): $(MKDIR.bld) $(post-jses.js) $(MAKEFILE) @$(call b.echo,@,$(emo.disk)); \ for i in $(post-jses.js); do \ echo "/* BEGIN FILE: $$i */"; \ cat $$i || exit $$?; \ echo "/* END FILE: $$i */"; \ done > $@ # # speedtest1 decls needed before the $(bin.mkws)-generated makefile # is included. # bin.speedtest1 = ../../speedtest1 speedtest1.c = ../../test/speedtest1.c speedtest1.c.in = $(speedtest1.c) $(sqlite3-wasm.c) EXPORTED_FUNCTIONS.speedtest1 = $(abspath $(dir.tmp)/EXPORTED_FUNCTIONS.speedtest1) # # fiddle build flags # # Flags specifically for debug builds of fiddle. Performance suffers # greatly in debug builds. ######################################################################## # shell.c and its build flags... # # We should ideally collect these from ../../configure and past # them in ./config.make. The problem with that is that SHELL_OPT is # generated at make-time, not configure-time. ifneq (1,$(MAKING_CLEAN)) make-np-0 = make -C $(dir.top) -n -p make-np-1 = sed -e 's/(TOP)/(dir.top)/g' # Extract SHELL_OPT and SHELL_DEP from the top-most makefile and import # them as vars here... $(eval $(shell $(make-np-0) | grep -e '^SHELL_OPT ' | $(make-np-1))) $(eval $(shell $(make-np-0) | grep -e '^SHELL_DEP ' | $(make-np-1))) # ^^^ can't do that in 1 invocation b/c newlines get stripped ifeq (,$(SHELL_OPT)) $(error Could not parse SHELL_OPT from $(dir.top)/Makefile.) endif ifeq (,$(SHELL_DEP)) $(error Could not parse SHELL_DEP from $(dir.top)/Makefile.) endif $(dir.top)/shell.c: $(SHELL_DEP) $(dir.tool)/mkshellc.tcl $(sqlite3.c) $(MAKE) -C $(dir.top) shell.c endif # /shell.c ######################################################################## EXPORTED_FUNCTIONS.fiddle = $(dir.tmp)/EXPORTED_FUNCTIONS.fiddle $(EXPORTED_FUNCTIONS.fiddle): $(fiddle.EXPORTED_FUNCTIONS.in) $(MAKEFILE_LIST) @$(b.mkdir@) @sort -u $(fiddle.EXPORTED_FUNCTIONS.in) > $@ @echo $(logtag.@) $(emo.disk) emcc.flags.fiddle = \ $(emcc.cflags) $(emcc_opt_full) \ --minify 0 \ -sALLOW_TABLE_GROWTH \ -sMEMORY64=$(emcc.MEMORY64) \ -sINITIAL_MEMORY=$(emcc.INITIAL_MEMORY.8) \ -sABORTING_MALLOC \ -sSTRICT_JS=0 \ -sENVIRONMENT=web,worker \ -sMODULARIZE \ -sDYNAMIC_EXECUTION=0 \ -sWASM_BIGINT=$(emcc.WASM_BIGINT) \ -sEXPORT_NAME=$(sqlite3.js.init-func) \ -Wno-limited-postlink-optimizations \ $(emcc.exportedRuntimeMethods),FS \ -sEXPORTED_FUNCTIONS=@$(abspath $(EXPORTED_FUNCTIONS.fiddle)) \ $(SQLITE_OPT.full-featured) \ $(SQLITE_OPT.common) \ $(SHELL_OPT) \ -UHAVE_READLINE -UHAVE_EDITLINE -UHAVE_LINENOISE \ -USQLITE_HAVE_ZLIB \ -USQLITE_WASM_BARE_BONES \ -DSQLITE_SHELL_FIDDLE clean: clean-fiddle clean-fiddle: rm -f $(dir.fiddle)/fiddle-module.js \ $(dir.fiddle)/*.wasm \ $(dir.fiddle)/sqlite3-opfs-*.js \ $(dir.fiddle)/*.gz \ EXPORTED_FUNCTIONS.fiddle rm -fr $(dir.fiddle-debug) emcc.flags.fiddle.debug = $(emcc.flags.fiddle) \ -DSQLITE_DEBUG \ -DSQLITE_ENABLE_SELECTTRACE \ -DSQLITE_ENABLE_WHERETRACE fiddle.EXPORTED_FUNCTIONS.in = \ EXPORTED_FUNCTIONS.fiddle.in \ $(dir.api)/EXPORTED_FUNCTIONS.sqlite3-core \ $(dir.api)/EXPORTED_FUNCTIONS.sqlite3-extras fiddle.c.in = $(dir.top)/shell.c $(sqlite3-wasm.c) # # WASMFS build - unsupported and untested. We used WASMFS # to jumpstart development early on, but it has always been # a moving target, in that Emscripten updates have broken # our build often enough that we no longer actively support it. # It's interesting to keep around, though. # # Only add wasmfs if wasmfs.enable=1 or we're running (dist)clean # ifneq (,$(filter wasmfs b-wasmfs for-testing,$(MAKECMDGOALS))) wasmfs.enable ?= 1 else # Unconditionally enable wasmfs for [dist]clean so that the wasmfs # sub-make can clean up. wasmfs.enable ?= $(MAKING_CLEAN) endif cflags.wasmfs = -DSQLITE_ENABLE_WASMFS # end wasmfs (the rest is in mkwasmbuilds.c) # # # $(bin.mkwb) is used for generating much of the makefile code for the # various wasm builds. It used to be generated in this makefile via a # difficult-to-read/maintain block of $(eval)'d code. Attempts were # made to generate it from tcl and bash (shell) but having to escape # the $ references in those languages made it just as illegible as the # native makefile code. Somewhat surprisingly, moving that code # generation to C makes it slightly less illegible than the previous 3 # options. # # Maintenance notes: # # - Ordering of this block within this file is fragile. The generated # makefile sets up many vars which are useful for the other targets. # # - Vars which are used by $(bin.mkwb) in dependency lists and such # need to be defined before this is included. Those used in recipies # may be defined after this step. # bin.mkwb = ./mkwasmbuilds ifneq (1,$(MAKING_CLEAN)) $(bin.mkwb): $(bin.mkwb).c $(MAKEFILE) $(CC) -O0 -g -std=c99 -o $@ $< -DWASM_CUSTOM_INSTANTIATE=$(WASM_CUSTOM_INSTANTIATE) .wasmbuilds.make: $(bin.mkwb) @rm -f $@ $(bin.mkwb) > $@ @chmod -w $@ -include .wasmbuilds.make endif CLEAN_FILES += .wasmbuilds.make $(bin.mkwb) # # $(sqlite3.ext.js) = API-related files which are standalone # files, not part of the amalgamation. This list holds # the name of each such _output_ file. # sqlite3.ext.js = ######################################################################## # We need separate copies of certain supplementary JS files for the # bundler-friendly build. Concretely, any supplemental JS files which # themselves use importScripts() or Workers or URL() constructors # which refer to other in-tree (m)JS files require a bundler-friendly # copy. Bundler-friendly builds replace certain references to string # vars/expressions with string literals, as bundler tools are static # code analyzers and cannot cope with the former. # # sqlite3-worker1*.* # TODO: 64-bit # define gen-worker1 # $1 = X.ext part of sqlite3-worker1X.ext # $2 = $(c-pp.D.NAME) $(call b.c-pp.target,filter,$(dir.api)/sqlite3-worker1.c-pp.js,\ $(dir.dout)/sqlite3-worker1$(1),$(2)) sqlite3.ext.js += $(dir.dout)/sqlite3-worker1$(1) all: $(dir.dout)/sqlite3-worker1$(1) endef $(eval $(call gen-worker1,.js,$(c-pp.D.vanilla))) $(eval $(call gen-worker1,.mjs,$(c-pp.D.esm))) $(eval $(call gen-worker1,-bundler-friendly.mjs,$(c-pp.D.bundler))) # # sqlite3-worker1-promiser*.* # TODO: 64-bit # define gen-promiser # $1 = X.ext part of sqlite3-worker1-promiserX.ext # $2 = $(c-pp.D.NAME) $(call b.c-pp.target,filter,$(dir.api)/sqlite3-worker1-promiser.c-pp.js,\ $(dir.dout)/sqlite3-worker1-promiser$(1),$(2)) sqlite3.ext.js += $(dir.dout)/sqlite3-worker1-promiser$(1) all: $(dir.dout)/sqlite3-worker1-promiser$(1) endef $(eval $(call gen-promiser,.js,$(c-pp.D.vanilla))) $(eval $(call gen-promiser,.mjs,$(c-pp.D.esm))) $(eval $(call gen-promiser,-bundler-friendly.mjs,$(c-pp.D.bundler))) # # demo1-worker-*.*: # $1 = .js or .mjs # $2 = .html or -esm.html # $3 = -D... flags for $(bin.c-pp) # define gen-dwp $(call b.c-pp.target,test,demo-worker1-promiser.c-pp.js,demo-worker1-promiser$(1),$(3)) $(call b.c-pp.target,test,demo-worker1-promiser.c-pp.html,demo-worker1-promiser$(2),$(3)) demos: demo-worker1-promiser$(1) demo-worker1-promiser$(2) endef $(eval $(call gen-dwp,.js,.html,$(c-pp.D.vanilla))) $(eval $(call gen-dwp,.mjs,-esm.html,$(c-pp.D.esm))) all: demos # End worker/promiser generation ####################################################################### # # "SOAP" is a static file which is not part of the amalgamation but # gets copied into the build output folder and into each of the fiddle # builds. # sqlite3.ext.js += $(dir.dout)/sqlite3-opfs-async-proxy.js $(dir.dout)/sqlite3-opfs-async-proxy.js: $(dir.api)/sqlite3-opfs-async-proxy.js @$(call b.cp,@,$<,$@) # # Add a dep of $(sqlite3.ext.js) on every individual build's JS file. # The primary purpose of this is to force them to be copied early in # the build process, which is sometimes a time-saver during # development, allowing the developer to reload a test page while # other parts of the build are still running. Another reason is that # we don't otherwise have a great place to attach them such that # they're always copied when we need them. # $(foreach B,$(b.names),$(eval $(out.$(B).js): $(sqlite3.ext.js))) # # b-all: builds all available js/wasm builds. # $(foreach B,$(b.names),$(eval b-all: $(out.$(B).js))) # # speedtest1 is our primary benchmarking tool. # # emcc.speedtest1.common = emcc flags used by multiple builds of speedtest1 # emcc.speedtest1 = emcc flags used by the main build of speedtest1 # # These flags get applied via $(bin.mkwb). emcc.speedtest1.common = $(emcc_opt_full) emcc.speedtest1 = -I. -I$(dir $(sqlite3.canonical.c)) emcc.speedtest1 += -sENVIRONMENT=web emcc.speedtest1 += -sALLOW_MEMORY_GROWTH emcc.speedtest1 += -sINITIAL_MEMORY=$(emcc.INITIAL_MEMORY.32) emcc.speedtest1.common += -sINVOKE_RUN=0 emcc.speedtest1.common += --no-entry emcc.speedtest1.common += -sABORTING_MALLOC emcc.speedtest1.common += -sSTRICT_JS=0 emcc.speedtest1.common += -sMODULARIZE emcc.speedtest1.common += -Wno-limited-postlink-optimizations emcc.speedtest1.common += -Wno-unused-main # ^^^^ -Wno-unused-main is for emcc 3.1.52+. speedtest1 has a wasm_main() which is # exported and called by the JS code. emcc.speedtest1.common += -sSTACK_SIZE=512KB emcc.speedtest1.common += -sEXPORTED_FUNCTIONS=@$(EXPORTED_FUNCTIONS.speedtest1) emcc.speedtest1.common += $(emcc.exportedRuntimeMethods) emcc.speedtest1.common += -sALLOW_TABLE_GROWTH emcc.speedtest1.common += -sDYNAMIC_EXECUTION=0 emcc.speedtest1.common += --minify 0 emcc.speedtest1.common += -sEXPORT_NAME=$(sqlite3.js.init-func) emcc.speedtest1.common += -sWASM_BIGINT=$(emcc.WASM_BIGINT) speedtest1.exit-runtime0 = -sEXIT_RUNTIME=0 speedtest1.exit-runtime1 = -sEXIT_RUNTIME=1 # Re -sEXIT_RUNTIME=1 vs 0: if it's 1 and speedtest1 crashes, we get # this error from Emscripten: # # > native function `free` called after runtime exit (use # NO_EXIT_RUNTIME to keep it alive after main() exits)) # # If it's 0 and it crashes, we get: # # > stdio streams had content in them that was not flushed. you should # set EXIT_RUNTIME to 1 (see the FAQ), or make sure to emit a newline # when you printf etc. # # and pending output is not flushed because it didn't end with a # newline (by design). The lesser of the two evils seems to be # -sEXIT_RUNTIME=1 but we need EXIT_RUNTIME=0 for the worker-based app # which runs speedtest1 multiple times. $(EXPORTED_FUNCTIONS.speedtest1): $(EXPORTED_FUNCTIONS.api.core) @$(call b.echo,@,$(emo.disk)); \ $(call b.mkdir@); \ { echo _wasm_main; cat $(EXPORTED_FUNCTIONS.api.core); } > $@ || exit speedtest1: b-speedtest1 # # Generate 64-bit variants of speedtest1*.{js,html} # define gen-st64 $(2): $(1) @$$(call b.echo,speedtest164,$$(emo.disk)$(emo.lock) Creating from $$<) @rm -f $$@; \ sed -e 's/$(3)\.js/$(3)-64bit\.js/' < $$< > $$@; \ chmod -w $$@ b-speedtest164: $(2) CLEAN_FILES += $(2) endef $(eval $(call gen-st64,speedtest1.html,speedtest1-64bit.html,speedtest1)) $(eval $(call gen-st64,speedtest1-worker.html,speedtest1-worker-64bit.html,speedtest1-worker)) $(eval $(call gen-st64,speedtest1-worker.js,speedtest1-worker-64bit.js,speedtest1-worker)) # end speedtest1.js ######################################################################## # # tester1 is the main unit and regression test application and needs # to be able to run in 4 separate modes to cover the primary # client-side use cases: # # 1) Load sqlite3 in the main UI thread of a conventional script. # 2) Load sqlite3 in a conventional Worker thread. # 3) Load sqlite3 as an ES6 module (ESM) in the main thread. # 4) Load sqlite3 as an ESM worker. (Not all browsers support this.) # # To that end, we require two separate builds of tester1.js: # # tester1.js: cases 1 and 2 # tester1.mjs: cases 3 and 4 # # Then we need those again in 64-bit builds, which require a 64-bit # pair of js/wasm files. # # To create those, we filter tester1.c-pp.js/html with $(bin.c-pp)... # tester1.js variants: define gen-tester1.js # $1 = build name to have dep on # $2 = suffix for tester1SUFFIX JS # $3 = $(bin.c-pp) flags $(call b.c-pp.target,test,tester1.c-pp.js,tester1$(2),$(3)) tester1$(2): $(sqlite3.ext.js) $(out.$(1).wasm) tester1-$(1): tester1$(2) tester1: tester1$(2) endef $(eval $(call gen-tester1.js,vanilla,.js, \ $(c-pp.D.vanilla) \ -Dsqlite3.js=$(dir.dout)/sqlite3.js)) $(eval $(call gen-tester1.js,vanilla64,-64bit.js, \ $(c-pp.D.vanilla64) \ -Dsqlite3.js=$(dir.dout)/sqlite3-64bit.js)) $(eval $(call gen-tester1.js,esm,.mjs, \ $(c-pp.D.esm) \ -Dsqlite3.js=$(dir.dout)/sqlite3.mjs)) $(eval $(call gen-tester1.js,esm64,-64bit.mjs, \ $(c-pp.D.esm64) \ -Dsqlite3.js=$(dir.dout)/sqlite3-64bit.mjs)) # tester1.html variants: define gen-tester1.html # $1 = build name to have a dep on # $2 = filename suffix: empty, -64bit, -esm, esm-64bit # $3 = $(bin.c-pp) flags $(call b.c-pp.target,test,tester1.c-pp.html,tester1$(2).html,$(3)) tester1$(2).html: tester1-$(1) tester1: tester1$(2).html endef $(eval $(call gen-tester1.html,vanilla,,\ $(c-pp.D.vanilla) \ -Dbitness=32 \ -Dtitle="UI thread" \ -Dtester1.js=tester1.js \ -Dsqlite3.js=$(dir.dout)/sqlite3.js)) $(eval $(call gen-tester1.html,vanilla64,-64bit,\ $(c-pp.D.vanilla64) \ -Dbitness=64 \ -Dtitle="UI thread" \ -Dtester1.js=tester1-64bit.js \ -Dsqlite3.js=$(dir.dout)/sqlite3-64bit.js)) $(eval $(call gen-tester1.html,esm,-esm,\ $(c-pp.D.esm) \ -Dbitness=32 \ -Dtitle="ES6 Module in UI thread" \ -Dtester1.js=tester1.mjs \ -Dsqlite3.js=$(dir.dout)/sqlite3.mjs)) $(eval $(call gen-tester1.html,esm64,-esm-64bit,\ $(c-pp.D.esm64) \ -Dbitness=64 \ -Dtitle="ES6 Module in UI thread" \ -Dtester1.js=tester1-64bit.mjs \ -Dsqlite3.js=$(dir.dout)/sqlite3-64bit.mjs)) # tester1-worker.html variants: # There is no ESM variant of this file. Instead, that page accepts a # ?esm URL flag to switch to ESM mode. $(eval $(call b.c-pp.target,test,tester1-worker.c-pp.html,\ tester1-worker.html,-Dbitness=32)) $(eval $(call b.c-pp.target,test,tester1-worker.c-pp.html,\ tester1-worker-64bit.html,$(c-pp.D.64bit) -Dbitness=64)) tester1: tester1-worker.html tester1-worker-64bit.html tester1-worker.html: tester1.mjs tester1-worker-64bit.html: tester1-64bit.mjs all: tester1 # end tester1 ######################################################################## # # Convenience rules to rebuild with various -Ox levels. Much # experimentation shows -O2 to be the clear winner in terms of speed. # -Oz results are significantly smaller and only slightly slower than # -O2 (very roughly 10% in highly unscientific tests), so -Oz is the # shipping configuration. # # Achtung: build times with anything higher than -O0 are somewhat # painful, which is why -O0 is the default. .PHONY: o0 o1 o2 o3 os oz emcc-opt-extra = #ifeq (1,$(wasm-bare-bones)) #emcc-opt-extra += -flto # ^^^^ -flto can have a considerably performance boost at -O0 but # doubles the build time and seems to have negligible, if any, effect # on higher optimization levels. # # -flto does not shrink the size of bare-bones builds by any measurable # amount. #endif o0: clean $(MAKE) -e "emcc_opt=-O0" o1: clean $(MAKE) -e "emcc_opt=-O1 $(emcc-opt-extra)" o2: clean $(MAKE) -e "emcc_opt=-O2 $(emcc-opt-extra)" o3: clean $(MAKE) -e "emcc_opt=-O3 $(emcc-opt-extra)" os: clean @echo "$(emo.fire)WARNING$(emo.fire): -Os can result in a build with mysteriously missing pieces!" $(MAKE) -e "emcc_opt=-Os $(emcc-opt-extra)" oz: clean $(MAKE) -e "emcc_opt=-Oz $(emcc-opt-extra)" # # Push files to the public wasm-testing.sqlite.org server. # # Ideally only -Oz builds should be pushed, so the practice has become: # # make clean # make -j4 for-testing # make push-testing # wasm-testing.include = *.js *.mjs *.html \ ./tests \ $(dir.dout) $(dir.common) $(dir.fiddle) $(dir.fiddle.debug) $(dir.jacc) wasm-testing.exclude = sql/speedtest1.sql jswasm/*/* wasm-testing.dir = /jail/sites/wasm-testing wasm-testing.dest ?= wasm-testing:$(wasm-testing.dir) # ---------------------^^^^^^^^^^^^ ssh alias .PHONY: push-testing push-testing: rsync -z -e ssh --ignore-times --chown=stephan:www-data --group -r \ $(patsubst %,--exclude=%,$(wasm-testing.exclude)) \ $(wasm-testing.include) $(wasm-testing.dest) @echo "Updating gzipped copies..."; \ ssh wasm-testing 'cd $(wasm-testing.dir) && bash .gzip' || \ echo "SSH failed: it's likely that stale content will be served via old gzip files." # build everything needed by push-testing with -Oz .PHONY: for-testing for-testing: emcc_opt=-Oz for-testing: loud=1 for-testing.deps = \ tester1 demos \ b-vanilla b-vanilla64 \ b-esm b-esm64 \ b-fiddle b-fiddle.debug \ b-speedtest1 b-speedtest164 \ b-wasmfs for-testing: $(for-testing.deps) ######################################################################## # If we find a copy of https://sqlite.org/wasm checked out, copy # certain files over to it, applying some automated edits... wasm.docs.home ?= ../../../wasm wasm.docs.found = $(if $(wildcard $(wasm.docs.home)/api-index.md),\ $(wildcard $(wasm.docs.home)),) .PHONY: update-docs ifeq (,$(wasm.docs.found)) update-docs: @echo "Cannot find wasm docs checkout."; \ echo "Pass wasm.docs.home=/path/to/wasm/docs/checkout or edit this makefile to suit."; \ exit 127 else wasm.docs.jswasm = $(wasm.docs.home)/jswasm update-docs: $(bin.stripccomments) $(out.sqlite3.js) $(out.sqlite3.wasm) @echo "Copying files to the /wasm docs. Be sure to use an -Oz build for this!"; cp -p $(sqlite3.wasm) $(wasm.docs.jswasm)/. $(bin.stripccomments) -k -k < $(out.vanilla.js) \ | sed -e '/^[ \t]*$$/d' > $(wasm.docs.jswasm)/sqlite3.js cp -p demo-123.js demo-123.html demo-123-worker.html $(wasm.docs.home)/. sed -n -e '/EXTRACT_BEGIN/,/EXTRACT_END/p' \ module-symbols.html > $(wasm.docs.home)/module-symbols.html endif # end /wasm docs ######################################################################## # Run local web server for the test/demo pages. httpd: althttpd -max-age 1 -enable-sab 1 -page index.html ######################################################################## # fiddle_remote is the remote destination for the fiddle app. It must # be a [user@]HOST:/path for rsync. The target "should probably" # contain a symlink of index.html -> fiddle.html. fiddle_remote ?= ifeq (,$(fiddle_remote)) ifneq (,$(wildcard /home/stephan)) fiddle_remote = wh:www/wasm-testing/fiddle/. else ifneq (,$(wildcard /home/drh)) #fiddle_remote = if appropriate, add that user@host:/path here endif endif push-fiddle: fiddle @if [ x = "x$(fiddle_remote)" ]; then \ echo "fiddle_remote must be a [user@]HOST:/path for rsync"; \ exit 1; \ fi rsync -va fiddle/ $(fiddle_remote) # end fiddle remote push ######################################################################## .PHONY: clean distclean clean: -rm -f $(CLEAN_FILES) -rm -fr $(dir.dout) $(dir.tmp) distclean: clean -rm -f $(DISTCLEAN_FILES) CLEAN_FILES += *~ $(dir.jacc)/*~ $(dir.api)/*~ $(dir.common)/*~ $(dir.fiddle)/*~ \ ######################################################################## # Create main client downloadable zip file: ifneq (,$(filter dist snapshot,$(MAKECMDGOALS))) ifeq (1,$(SQLITE_C_IS_SEE)) dist-name-extra = -see else dist-name-extra = endif dist-name-prefix = sqlite-wasm$(dist-name-extra) .PHONY: dist dist: ./mkdist.sh $(dist-name-prefix) snapshot: ./mkdist.sh $(dist-name-prefix) --snapshot endif # ^^^ making dist/snapshot CLEAN_FILES += $(wildcard sqlite-wasm-*.zip) ######################################################################## # Explanation of, and some commentary on, various emcc build flags # follows. Full docs for these can be found at: # # https://github.com/emscripten-core/emscripten/blob/main/src/settings.js # # -sENVIRONMENT=web: elides bootstrap code related to non-web JS # environments like node.js. Removing this makes the output a tiny # tick larger but hypothetically makes it more portable to # non-browser JS environments. # # -sMODULARIZE: changes how the generated code is structured to avoid # declaring a global Module object and instead installing a function # which loads and initializes the module. The function is named... # # -sEXPORT_NAME=jsFunctionName (see -sMODULARIZE) # # -sEXPORTED_RUNTIME_METHODS=@/absolute/path/to/file: a file # containing a list of emscripten-supplied APIs, one per line, which # must be exported into the generated JS. Must be an absolute path! # # -sEXPORTED_FUNCTIONS=@/absolute/path/to/file: a file containing a # list of C functions, one per line, which must be exported via wasm # so they're visible to JS. C symbols names in that file must all # start with an underscore for reasons known only to the emcc # developers. e.g., _sqlite3_open_v2 and _sqlite3_finalize. Must be # an absolute path! # # -sSTRICT_JS ensures that the emitted JS code includes the 'use # strict' option. Note that -sSTRICT is more broadly-scoped and # results in build errors. # # -sALLOW_TABLE_GROWTH is required for (at a minimum) the UDF-binding # feature. Without it, JS functions cannot be made to proxy C-side # callbacks. # # -sABORTING_MALLOC causes the JS-bound _malloc() to abort rather than # return 0 on OOM. If set to 0 then all code which uses _malloc() # must, just like in C, check the result before using it, else # they're likely to corrupt the JS/WASM heap by writing to its # address of 0. It is, as of this writing, enabled in Emscripten by # default but we enable it explicitly in case that default changes. # # -sDYNAMIC_EXECUTION=0 disables eval() and the Function constructor. # If the build runs without these, it's preferable to use this flag # because certain execution environments disallow those constructs. # This flag is not strictly necessary, however. # # --no-entry: for compiling library code with no main(). If this is # not supplied and the code has a main(), it is called as part of the # module init process. Note that main() is #if'd out of shell.c # (renamed) when building in wasm mode. # # --pre-js/--post-js=FILE relative or absolute paths to JS files to # prepend/append to the emcc-generated bootstrapping JS. It's # easier/faster to develop with separate JS files (reduces rebuilding # requirements) but certain configurations, namely -sMODULARIZE, may # require using at least a --pre-js file. They can be used # individually and need not be paired. # # -O0..-O3 and -Oz: optimization levels affect not only C-style # optimization but whether or not the resulting generated JS code # gets minified. -O0 compiles _much_ more quickly than -O3 or -Oz, # and doesn't minimize any JS code, so is recommended for # development. -O3 or -Oz are recommended for deployment, but # primarily because -Oz will shrink the wasm file notably. JS-side # minification makes little difference in terms of overall # distributable size. # # --minify 0: supposedly disables minification of the generated JS # code, regardless of optimization level, but that's not quite true: # search the main makefile for wasm-strip for details. Minification # of the JS has minimal overall effect in the larger scheme of things # and results in JS files which can neither be edited nor viewed as # text files in Fossil (which flags them as binary because of their # extreme line lengths). Interestingly, whether or not the comments # in the generated JS file get stripped is unaffected by this setting # and depends entirely on the optimization level. Higher optimization # levels reduce the size of the JS considerably even without # minification. # ########################################################################