//

// @license

// Copyright 2010 The Emscripten Authors

// SPDX-License-Identifier: MIT

//

//

// Various compiler settings. These are simply variables present when the

// JS compiler runs. To set them, do something like:

//

// emcc -s OPTION1=VALUE1 -s OPTION2=VALUE2 [..other stuff..]

//

// For convenience and readability `-s OPTION` expands to `-s OPTION=1`

// and `-s NO_OPTION` expands to `-s OPTION=0` (assuming OPTION is a valid

// option).

//

// See https://github.com/emscripten-core/emscripten/wiki/Code-Generation-Modes/

//

// Note that the values here are the defaults in -O0, that is, unoptimized

// mode. See apply_opt_level in tools/shared.py for how -O1,2,3 affect these

// flags.

//

// These flags should only have an effect when compiling to JS, so there

// should not be a need to have them when just compiling source to

// bitcode. However, there will also be no harm either, so it is ok to.

//

// Settings in this file can be directly set from the command line. Internal

// settings that are not part of the user ABI live in the settings_internal.js.

//

// In general it is best to pass the same arguments at both compile and link

// time, as whether wasm object files are used or not affects when codegen

// happens (without wasm object files, codegen is done entirely during

// link; otherwise, it is during compile). Flags affecting codegen must

// be passed when codegen happens, so to let a build easily switch when codegen

// happens (LTO vs normal), pass the flags at both times. The flags are also

// annotated in this file:

//

// [link] - Should be passed at link time. This is the case for all JS flags,

// as we emit JS at link (and that is most of the flags here, and

// hence the default).

// [compile+link] - A flag that has an effect at both compile and link time,

// basically any time emcc is invoked. The same flag should be

// passed at both times in most cases.

//

// If not otherwise specified, a flag is [link]. Note that no flag is only

// relevant during compile time, as during link we may do codegen for system

// libraries and other support code, so all flags are either link or

// compile+link.

//

// Tuning

// Whether we should add runtime assertions, for example to

// check that each allocation to the stack does not

// exceed its size, whether all allocations (stack and static) are

// of positive size, etc., whether we should throw if we encounter a bad __label__, i.e.,

// if code flow runs into a fault

// ASSERTIONS == 2 gives even more runtime checks, that may be very slow. That

// includes internal dlmalloc assertions.

var ASSERTIONS = 1;

// Whether extra logging should be enabled.

// This logging isn't quite assertion-quality in that it isn't necessarily a

// symptom that something is wrong.

var RUNTIME_LOGGING = 0;

// Chooses what kind of stack smash checks to emit to generated code:

// 0: Stack overflows are not checked.

// 1: Adds a security cookie at the top of the stack, which is checked at end of

// each tick and at exit (practically zero performance overhead)

// -s ASSERTIONS=1 automatically enables -s STACK_OVERFLOW_CHECK=1.

// 2: Same as above, but also adds an explicit check for allocate() calls which

// call ALLOC_STACK. Has a small performance cost.

var STACK_OVERFLOW_CHECK = 0;

// When set to 1, will generate more verbose output during compilation.

var VERBOSE = 0;

// Whether we will run the main() function. Disable if you embed the generated

// code in your own, and will call main() yourself at the right time (which you

// can do with Module.callMain(), with an optional parameter of commandline args).

var INVOKE_RUN = 1;

// If 0, the runtime is not quit when main() completes (allowing code to

// run afterwards, for example from the browser main event loop). atexit()s

// are also not executed, and we can avoid including code for runtime shutdown,

// like flushing the stdio streams.

// Set this to 1 if you do want atexit()s or stdio streams to be flushed

// on exit.

// This setting is controlled automatically in STANDALONE_WASM mode:

// - For a command (has a main function) this is always 1

// - For a reactor (no a main function) this is always 0

var EXIT_RUNTIME = 0;

// How to represent the initial memory content.

// 0: embed a base64 string literal representing the initial memory data

// 1: create a *.mem file containing the binary data of the initial memory;

// use the --memory-init-file command line switch to select this method

// 2: embed a string literal representing that initial memory data

var MEM_INIT_METHOD = 0;

// The total stack size. There is no way to enlarge the stack, so this

// value must be large enough for the program's requirements. If

// assertions are on, we will assert on not exceeding this, otherwise,

// it will fail silently.

var TOTAL_STACK = 5*1024*1024;

// What malloc()/free() to use, out of

// * dlmalloc - a powerful general-purpose malloc

// * emmalloc - a simple and compact malloc designed for emscripten

// * none - no malloc() implementation is provided, but you must implement

// malloc() and free() yourself.

// dlmalloc is necessary for split memory and other special modes, and will be

// used automatically in those cases.

// In general, if you don't need one of those special modes, and if you don't

// allocate very many small objects, you should use emmalloc since it's

// smaller. Otherwise, if you do allocate many small objects, dlmalloc

// is usually worth the extra size. dlmalloc is also a good choice if you want

// the extra security checks it does (such as noticing metadata corruption in

// its internal data structures, which emmalloc does not do).

var MALLOC = "dlmalloc";

// If 1, then when malloc would fail we abort(). This is nonstandard behavior,

// but makes sense for the web since we have a fixed amount of memory that

// must all be allocated up front, and so (a) failing mallocs are much more

// likely than on other platforms, and (b) people need a way to find out

// how big that initial allocation (INITIAL_MEMORY) must be.

// If you set this to 0, then you get the standard malloc behavior of

// returning NULL (0) when it fails.

//

// Setting ALLOW_MEMORY_GROWTH turns this off, as in that mode we default to

// the behavior of trying to grow and returning 0 from malloc on failure, like

// a standard system would. However, you can still set this flag to override

// that.

// * This is a mostly-backwards-compatible change. Previously this option

// was ignored when growth was on. The current behavior is that growth

// turns it off by default, so for users that never specified the flag

// nothing changes. But if you do specify it, it will have an effect now,

// which it did not previously. If you don't want that, just stop passing

// it in at link time.

//

// [link]

var ABORTING_MALLOC = 1;

// The initial amount of memory to use. Using more memory than this will

// cause us to expand the heap, which can be costly with typed arrays:

// we need to copy the old heap into a new one in that case.

// If ALLOW_MEMORY_GROWTH is set, this initial amount of memory can increase

// later; if not, then it is the final and total amount of memory.

//

// (This option was formerly called TOTAL_MEMORY.)

var INITIAL_MEMORY = 16777216;

// Set the maximum size of memory in the wasm module (in bytes). This is only

// relevant when ALLOW_MEMORY_GROWTH is set, as without growth, the size of

// INITIAL_MEMORY is the final size of memory anyhow.

//

// If this value is -1, it means there is no specified limit.

//

// Note that the default value here is 2GB, which means that by default if you

// enable memory growth then we can grow up to 2GB but no higher. 2GB is a

// natural limit for several reasons:

//

// * If the maximum heap size is over 2GB, then pointers must be unsigned in

// JavaScript, which increases code size. We don't want memory growth builds

// to be larger unless someone explicitly opts in to >2GB+ heaps.

// * Historically no VM has supported more >2GB+, and only recently (Mar 2020)

// has support started to appear. As support is limited, it's safer for

// people to opt into >2GB+ heaps rather than get a build that may not

// work on all VMs.

//

// (This option was formerly called WASM_MEM_MAX and BINARYEN_MEM_MAX.)

var MAXIMUM_MEMORY = 2147483648;

// If false, we abort with an error if we try to allocate more memory than

// we can (INITIAL_MEMORY). If true, we will grow the memory arrays at

// runtime, seamlessly and dynamically. This has a performance cost in asm.js,

// both during the actual growth and in general (the latter is because in

// that case we must be careful about optimizations, in particular the

// eliminator), but in wasm it is efficient and should be used whenever relevant.

// See https://code.google.com/p/v8/issues/detail?id=3907 regarding

// memory growth performance in chrome.

// Note that growing memory means we replace the JS typed array views, as

// once created they cannot be resized. (This happens both in asm.js and in

// wasm - in wasm we can grow the Memory, but still need to create new

// views for JS.)

// Setting this option on will disable ABORTING_MALLOC, in other words,

// ALLOW_MEMORY_GROWTH enables fully standard behavior, of both malloc

// returning 0 when it fails, and also of being able to allocate more

// memory from the system as necessary.

var ALLOW_MEMORY_GROWTH = 0;

// If ALLOW_MEMORY_GROWTH is true, this variable specifies the geometric

// overgrowth rate of the heap at resize. Specify MEMORY_GROWTH_GEOMETRIC_STEP=0

// to disable overgrowing the heap at all, or e.g.

// MEMORY_GROWTH_GEOMETRIC_STEP=1.0 to double the heap (+100%) at every grow step.

// The larger this value is, the more memory the WebAssembly heap overreserves

// to reduce performance hiccups coming from memory resize, and the smaller

// this value is, the more memory is conserved, at the performance of more

// stuttering when the heap grows. (profiled to be on the order of ~20 msecs)

var MEMORY_GROWTH_GEOMETRIC_STEP = 0.20;

// Specifies a cap for the maximum geometric overgrowth size, in bytes. Use

// this value to constrain the geometric grow to not exceed a specific rate.

// Pass MEMORY_GROWTH_GEOMETRIC_CAP=0 to disable the cap and allow unbounded

// size increases.

var MEMORY_GROWTH_GEOMETRIC_CAP = 96*1024*1024;

// If ALLOW_MEMORY_GROWTH is true and MEMORY_GROWTH_LINEAR_STEP == -1, then

// geometric memory overgrowth is utilized (above variable). Set

// MEMORY_GROWTH_LINEAR_STEP to a multiple of WASM page size (64KB), eg. 16MB to

// replace geometric overgrowth rate with a constant growth step size. When

// MEMORY_GROWTH_LINEAR_STEP is used, the variables MEMORY_GROWTH_GEOMETRIC_STEP

// and MEMORY_GROWTH_GEOMETRIC_CAP are ignored.

var MEMORY_GROWTH_LINEAR_STEP = -1;

// If true, allows more functions to be added to the table at runtime. This is

// necessary for dynamic linking, and set automatically in that mode.

var ALLOW_TABLE_GROWTH = 0;

// where global data begins; the start of static memory. -1 means use the

// default, any other value will be used as an override

var GLOBAL_BASE = -1;

// Warn at compile time about instructions that LLVM tells us are not fully

// aligned. This is useful to find places in your code where you might refactor

// to ensure proper alignment. This is currently only supported in asm.js, not

// wasm.

var WARN_UNALIGNED = 0;

// Whether closure compiling is being run on this output

var USE_CLOSURE_COMPILER = 0;

// Specifies how warnings emitted by Closure are treated. Possible

// options: 'quiet', 'warn', 'error'. If set to 'warn', Closure warnings are printed

// out to console. If set to 'error', Closure warnings are treated like errors,

// similar to -Werror compiler flag.

var CLOSURE_WARNINGS = 'quiet';

// If set to 1, each asm.js/wasm module export is individually declared with a

// JavaScript "var" definition. This is the simple and recommended approach.

// However, this does increase code size (especially if you have many such

// exports), which can be avoided in an unsafe way by setting this to 0. In that

// case, no "var" is created for each export, and instead a loop (of small

// constant code size, no matter how many exports you have) writes all the

// exports received into the global scope. Doing so is dangerous since such

// modifications of the global scope can confuse external JS minifier tools, and

// also things can break if the scope the code is in is not the global scope

// (e.g. if you manually enclose them in a function scope).

var DECLARE_ASM_MODULE_EXPORTS = 1;

// Ignore closure warnings and errors (like on duplicate definitions)

var IGNORE_CLOSURE_COMPILER_ERRORS = 0;

// A limit on inlining. If 0, we will inline normally in LLVM and closure. If

// greater than 0, we will *not* inline in LLVM, and we will prevent inlining of

// functions of this size or larger in closure. 50 is a reasonable setting if

// you do not want inlining

// [compile+link]

var INLINING_LIMIT = 0;

// Check each write to the heap, for example, this will give a clear

// error on what would be segfaults in a native build (like dereferencing

// 0). See runtime_safe_heap.js for the actual checks performed.

var SAFE_HEAP = 0;

// Log out all SAFE_HEAP operations

var SAFE_HEAP_LOG = 0;

// Allows function pointers to be cast, wraps each call of an incorrect type

// with a runtime correction. This adds overhead and should not be used

// normally. It also forces ALIASING_FUNCTION_POINTERS to 0. Aside from making

// calls not fail, this tries to convert values as best it can. In asm.js, this

// uses doubles as the JS number type, so if you send a double to a parameter

// accepting an int, it will be |0-d into a (signed) int. In wasm, we have i64s

// so that is not valid, and instead we use 64 bits to represent values, as if

// we wrote the sent value to memory and loaded the received type from the same

// memory (using truncs/extends/ reinterprets). This means that when types do

// not match the emulated values may differ between asm.js and wasm (and native,

// for that matter - this is all undefined behavior). In any case, both

// approaches appear good enough to support Python, which is the main use case

// motivating this feature.

var EMULATE_FUNCTION_POINTER_CASTS = 0;

// Print out exceptions in emscriptened code. Does not work in asm.js mode

var EXCEPTION_DEBUG = 0;

// If 1, build in libcxxabi's full c++ demangling code, to allow stackTrace()

// to emit fully proper demangled c++ names

var DEMANGLE_SUPPORT = 0;

// Print out when we enter a library call (library*.js). You can also unset

// Runtime.debug at runtime for logging to cease, and can set it when you want

// it back. A simple way to set it in C++ is

// emscripten_run_script("Runtime.debug = ...;");

var LIBRARY_DEBUG = 0;

// Print out all musl syscalls, including translating their numeric index

// to the string name, which can be convenient for debugging. (Other system

// calls are not numbered and already have clear names; use LIBRARY_DEBUG

// to get logging for all of them.)

var SYSCALL_DEBUG = 0;

// Log out socket/network data transfer.

var SOCKET_DEBUG = 0;

// Select socket backend, either webrtc or websockets. XXX webrtc is not

// currently tested, may be broken

// As well as being configurable at compile time via the "-s" option the

// WEBSOCKET_URL and WEBSOCKET_SUBPROTOCOL

// settings may configured at run time via the Module object e.g.

// Module['websocket'] = {subprotocol: 'base64, binary, text'};

// Module['websocket'] = {url: 'wss://', subprotocol: 'base64'};

// You can set 'subprotocol' to null, if you don't want to specify it

// Run time configuration may be useful as it lets an application select

// multiple different services.

var SOCKET_WEBRTC = 0;

// A string containing either a WebSocket URL prefix (ws:// or wss://) or a complete

// RFC 6455 URL - "ws[s]:" "//" host [ ":" port ] path [ "?" query ].

// In the (default) case of only a prefix being specified the URL will be constructed from

// prefix + addr + ':' + port

// where addr and port are derived from the socket connect/bind/accept calls.

var WEBSOCKET_URL = 'ws://';

// If 1, the POSIX sockets API uses a native bridge process server to proxy sockets calls

// from browser to native world.

var PROXY_POSIX_SOCKETS = 0;

// A string containing a comma separated list of WebSocket subprotocols

// as would be present in the Sec-WebSocket-Protocol header.

// You can set 'null', if you don't want to specify it.

var WEBSOCKET_SUBPROTOCOL = 'binary';

// Print out debugging information from our OpenAL implementation.

var OPENAL_DEBUG = 0;

// If 1, prints out debugging related to calls from emscripten_web_socket_* functions

// in emscripten/websocket.h.

// If 2, additionally traces bytes communicated via the sockets.

var WEBSOCKET_DEBUG = 0;

// Adds extra checks for error situations in the GL library. Can impact

// performance.

var GL_ASSERTIONS = 0;

// If enabled, prints out all API calls to WebGL contexts. (*very* verbose)

var TRACE_WEBGL_CALLS = 0;

// Enables more verbose debug printing of WebGL related operations. As with

// LIBRARY_DEBUG, this is toggleable at runtime with option GL.debug.

var GL_DEBUG = 0;

// When enabled, sets preserveDrawingBuffer in the context, to allow tests to

// work (but adds overhead)

var GL_TESTING = 0;

// How large GL emulation temp buffers are

var GL_MAX_TEMP_BUFFER_SIZE = 2097152;

// Enables some potentially-unsafe optimizations in GL emulation code

var GL_UNSAFE_OPTS = 1;

// Forces support for all GLES2 features, not just the WebGL-friendly subset.

var FULL_ES2 = 0;

// If true, glGetString() for GL_VERSION and GL_SHADING_LANGUAGE_VERSION will

// return strings OpenGL ES format "Open GL ES ... (WebGL ...)" rather than the

// WebGL format. If false, the direct WebGL format strings are returned. Set

// this to true to make GL contexts appear like an OpenGL ES context in these

// version strings (at the expense of a little bit of added code size), and to

// false to make GL contexts appear like WebGL contexts and to save some bytes

// from the output.

var GL_EMULATE_GLES_VERSION_STRING_FORMAT = 1;

// If true, all GL extensions are advertised in both unprefixed WebGL extension

// format, but also in desktop/mobile GLES/GL extension format with "GL_" prefix.

var GL_EXTENSIONS_IN_PREFIXED_FORMAT = 1;

// If true, adds support for automatically enabling all GL extensions for

// GLES/GL emulation purposes. This takes up code size. If you set this to 0,

// you will need to manually enable the extensions you need.

var GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS = 1;

// If true, the function emscripten_webgl_enable_extension() can be called to

// enable any WebGL extension. If false, to save code size,

// emscripten_webgl_enable_extension() cannot be called to enable any of extensions

// 'ANGLE_instanced_arrays', 'OES_vertex_array_object', 'WEBGL_draw_buffers',

// 'WEBGL_multi_draw', or 'WEBGL_draw_instanced_base_vertex_base_instance',

// but the dedicated functions emscripten_webgl_enable_*()

// found in html5.h are used to enable each of those extensions.

// This way code size is increased only for the extensions that are actually used.

// N.B. if setting this to 0, GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS must be set

// to zero as well.

var GL_SUPPORT_SIMPLE_ENABLE_EXTENSIONS = 1;

// If set to 0, Emscripten GLES2->WebGL translation layer does not track the kind

// of GL errors that exist in GLES2 but do not exist in WebGL. Settings this to 0

// saves code size. (Good to keep at 1 for development)

var GL_TRACK_ERRORS = 1;

// If true, GL contexts support the explicitSwapControl context creation flag.

// Set to 0 to save a little bit of space on projects that do not need it.

var GL_SUPPORT_EXPLICIT_SWAP_CONTROL = 0;

// If true, calls to glUniform*fv and glUniformMatrix*fv utilize a pool of

// preallocated temporary buffers for common small sizes to avoid generating

// temporary garbage for WebGL 1. Disable this to optimize generated size of the

// GL library a little bit, at the expense of generating garbage in WebGL 1. If

// you are only using WebGL 2 and do not support WebGL 1, this is not needed and

// you can turn it off.

var GL_POOL_TEMP_BUFFERS = 1;

// Some old Android WeChat (Chromium 37?) browser has a WebGL bug that it ignores

// the offset of a typed array view pointing to an ArrayBuffer. Set this to

// 1 to enable a polyfill that works around the issue when it appears. This

// bug is only relevant to WebGL 1, the affected browsers do not support WebGL 2.

var WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG = 0;

// Deprecated. Pass -s MAX_WEBGL_VERSION=2 to target WebGL 2.0.

var USE_WEBGL2 = 0;

// Specifies the lowest WebGL version to target. Pass -s MIN_WEBGL_VERSION=1

// to enable targeting WebGL 1, and -s MIN_WEBGL_VERSION=2 to drop support

// for WebGL 1.0

var MIN_WEBGL_VERSION = 1;

// Specifies the highest WebGL version to target. Pass -s MAX_WEBGL_VERSION=2

// to enable targeting WebGL 2. If WebGL 2 is enabled, some APIs (EGL, GLUT, SDL)

// will default to creating a WebGL 2 context if no version is specified.

// Note that there is no automatic fallback to WebGL1 if WebGL2 is not supported

// by the user's device, even if you build with both WebGL1 and WebGL2

// support, as that may not always be what the application wants. If you want

// such a fallback, you can try to create a context with WebGL2, and if that

// fails try to create one with WebGL1.

var MAX_WEBGL_VERSION = 1;

// If true, emulates some WebGL 1 features on WebGL 2 contexts, meaning that

// applications that use WebGL 1/GLES 2 can initialize a WebGL 2/GLES3 context,

// but still keep using WebGL1/GLES 2 functionality that no longer is supported

// in WebGL2/GLES3. Currently this emulates GL_EXT_shader_texture_lod extension

// in GLSLES 1.00 shaders, support for unsized internal texture formats, and the

// GL_HALF_FLOAT_OES != GL_HALF_FLOAT mixup.

var WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION = 0;

// Forces support for all GLES3 features, not just the WebGL2-friendly subset.

// This automatically turns on FULL_ES2 and WebGL2 support.

var FULL_ES3 = 0;

// Includes code to emulate various desktop GL features. Incomplete but useful

// in some cases, see

// http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html

var LEGACY_GL_EMULATION = 0;

// If you specified LEGACY_GL_EMULATION = 1 and only use fixed function pipeline

// in your code, you can also set this to 1 to signal the GL emulation layer

// that it can perform extra optimizations by knowing that the user code does

// not use shaders at all. If LEGACY_GL_EMULATION = 0, this setting has no

// effect.

var GL_FFP_ONLY = 0;

// If you want to create the WebGL context up front in JS code, set this to 1

// and set Module['preinitializedWebGLContext'] to a precreated WebGL context.

// WebGL initialization afterwards will use this GL context to render.

var GL_PREINITIALIZED_CONTEXT = 0;

// Enables support for WebGPU (via "webgpu/webgpu.h").

var USE_WEBGPU = 0;

// Enables building of stb-image, a tiny public-domain library for decoding

// images, allowing decoding of images without using the browser's built-in

// decoders. The benefit is that this can be done synchronously, however, it

// will not be as fast as the browser itself. When enabled, stb-image will be

// used automatically from IMG_Load and IMG_Load_RW. You can also call the

// stbi_* functions directly yourself.

var STB_IMAGE = 0;

// If WORKAROUND_IOS_9_RIGHT_SHIFT_BUG==1, work around Safari/WebKit bug in iOS 9.3.5: https://bugs.webkit.org/show_bug.cgi?id=151514 where computing "a >> b" or "a >>> b" in

// JavaScript would erroneously output 0 when a!=0 and b==0, after suitable JIT compiler optimizations have been applied to a function at runtime (bug does not

// occur in debug builds). Fix was landed in https://trac.webkit.org/changeset/196591/webkit on Feb 15th 2016. iOS 9.3.5 was released on August 25 2016, but

// oddly did not have the fix. iOS Safari 10.3.3 was released on July 19 2017, that no longer has the issue. Unknown which released version between these was the

// first to contain the fix, though notable is that iOS 9.3.5 and iOS 10.3.3 are the two consecutive "end-of-life" versions of iOS that users are likely

// to be on, e.g. iPhone 4s, iPad 2, iPad 3, iPad Mini 1, Pod Touch 5 all had end-of-life at iOS 9.3.5 (tested to be affected),

// and iPad 4, iPhone 5 and iPhone 5c all had end-of-life at iOS 10.3.3 (confirmed not affected).

// If you do not care about old iOS 9 support, keep this disabled.

var WORKAROUND_IOS_9_RIGHT_SHIFT_BUG = 0;

// From Safari 8 (where WebGL was introduced to Safari) onwards, OES_texture_half_float and OES_texture_half_float_linear extensions

// are broken and do not function correctly, when used as source textures.

// See https://bugs.webkit.org/show_bug.cgi?id=183321, https://bugs.webkit.org/show_bug.cgi?id=169999,

// https://stackoverflow.com/questions/54248633/cannot-create-half-float-oes-texture-from-uint16array-on-ipad

var GL_DISABLE_HALF_FLOAT_EXTENSION_IF_BROKEN = 0;

// Use JavaScript math functions like Math.tan. This saves code size as we can avoid shipping

// compiled musl code. However, it can be significantly slower as it calls out to JS. It

// also may give different results as JS math is specced somewhat differently than libc, and

// can also vary between browsers.

var JS_MATH = 0;

// If set, enables polyfilling for Math.clz32, Math.trunc, Math.imul, Math.fround.

var POLYFILL_OLD_MATH_FUNCTIONS = 0;

// Set this to enable compatibility emulations for old JavaScript engines. This gives you

// the highest possible probability of the code working everywhere, even in rare old

// browsers and shell environments. Specifically:

// * Add polyfilling for Math.clz32, Math.trunc, Math.imul, Math.fround. (-s POLYFILL_OLD_MATH_FUNCTIONS=1)

// * Work around iOS 9 right shift bug (-s WORKAROUND_IOS_9_RIGHT_SHIFT_BUG=1)

// * Work around old Chromium WebGL 1 bug (-s WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG=1)

// * Disable WebAssembly. (Must be paired with -s WASM=0)

// * Adjusts MIN_X_VERSION settings to 0 to include support for all browser versions.

// You can also configure the above options individually.

var LEGACY_VM_SUPPORT = 0;

// By default, emscripten output will run on the web, in a web worker,

// in node.js, or in a JS shell like d8, js, or jsc. You can set this option to

// specify that the output should only run in one particular environment, which

// must be one of

// 'web' - the normal web environment.

// 'webview' - just like web, but in a webview like Cordova;

// considered to be same as "web" in almost every place

// 'worker' - a web worker environment.

// 'node' - Node.js.

// 'shell' - a JS shell like d8, js, or jsc.

// Or it can be a comma-separated list of them, e.g., "web,worker". If this is

// the empty string, then all runtime environments are supported.

//

// Note that the set of environments recognized here is not identical to the

// ones we identify at runtime using ENVIRONMENT_IS_*. Specifically:

// * We detect whether we are a pthread at runtime, but that's set for workers

// and not for the main file so it wouldn't make sense to specify here.

// * The webview target is basically a subset of web. It must be specified

// alongside web (e.g. "web,webview") and we only use it for code generation

// at compile time, there is no runtime behavior change.

var ENVIRONMENT = '';

// Enable this to support lz4-compressed file packages. They are stored compressed in memory, and

// decompressed on the fly, avoiding storing the entire decompressed data in memory at once.

// If you run the file packager separately, you still need to build the main program with this flag,

// and also pass --lz4 to the file packager.

// (You can also manually compress one on the client, using LZ4.loadPackage(), but that is less

// recommended.)

// Limitations:

// * LZ4-compressed files are only decompressed when needed, so they are not available

// for special preloading operations like pre-decoding of images using browser codecs,

// preloadPlugin stuff, etc.

// * LZ4 files are read-only.

var LZ4 = 0;

// Emscripten exception handling options.

// These options only pertain to Emscripten exception handling and do not

// control the experimental native wasm exception handling option.

// Disables generating code to actually catch exceptions. This disabling is on

// by default as the overhead of exceptions is quite high in size and speed

// currently (in the future, wasm should improve that). When exceptions are

// disabled, if an exception actually happens then it will not be caught

// and the program will halt (so this will not introduce silent failures).

// There are 3 specific modes here:

// DISABLE_EXCEPTION_CATCHING = 0 - generate code to actually catch exceptions

// DISABLE_EXCEPTION_CATCHING = 1 - disable exception catching at all

// DISABLE_EXCEPTION_CATCHING = 2 - disable exception catching, but enables

// catching in list of allowed functions

// XXX note that this removes *catching* of exceptions, which is the main

// issue for speed, but you should build source files with

// -fno-exceptions to really get rid of all exceptions code overhead,

// as it may contain thrown exceptions that are never caught (e.g.

// just using std::vector can have that). -fno-rtti may help as well.

//

// [compile+link] - affects user code at compile and system libraries at link

var DISABLE_EXCEPTION_CATCHING = 1;

// Enables catching exception in the listed functions only, if

// DISABLE_EXCEPTION_CATCHING = 2 is set

// [compile+link] - affects user code at compile and system libraries at link

var EXCEPTION_CATCHING_ALLOWED = [];

// By default we handle exit() in node, by catching the Exit exception. However,

// this means we catch all process exceptions. If you disable this, then we no

// longer do that, and exceptions work normally, which can be useful for libraries

// or programs that don't need exit() to work.

// Emscripten uses an ExitStatus exception to halt when exit() is called.

// With this option, we prevent that from showing up as an unhandled

// exception.

var NODEJS_CATCH_EXIT = 1;

// Catch unhandled rejections in node. Without this, node may print the error,

// and that this behavior will change in future node, wait a few seconds, and

// then exit with 0 (which hides the error if you don't read the log). With

// this, we catch any unhandled rejection and throw an actual error, which will

// make the process exit immediately with a non-0 return code.

var NODEJS_CATCH_REJECTION = 1;

// Whether to transform the code using asyncify. This makes it possible to

// call JS functions from synchronous-looking code in C/C++.

// See https://emscripten.org/docs/porting/asyncify.html

var ASYNCIFY = 0;

// Imports which can do an sync operation, in addition to the default ones that

// emscripten defines like emscripten_sleep. If you add more you will need to

// mention them to here, or else they will not work (in ASSERTIONS builds an

// error will be shown).

// Note that this list used to contain the default ones, which meant that you

// had to list them when adding your own; the default ones are now added

// automatically.

var ASYNCIFY_IMPORTS = [];

// Whether indirect calls can be on the stack during an unwind/rewind.

// If you know they cannot, then setting this can be extremely helpful, as otherwise asyncify

// must assume an indirect call can reach almost everywhere.

var ASYNCIFY_IGNORE_INDIRECT = 0;

// The size of the asyncify stack - the region used to store unwind/rewind

// info. This must be large enough to store the call stack and locals. If it is too

// small, you will see a wasm trap due to executing an "unreachable" instruction.

// In that case, you should increase this size.

var ASYNCIFY_STACK_SIZE = 4096;

// If the Asyncify remove-list is provided, then the functions in it will not

// be instrumented even if it looks like they need to. This can be useful

// if you know things the whole-program analysis doesn't, like if you

// know certain indirect calls are safe and won't unwind. But if you

// get the list wrong things will break (and in a production build user

// input might reach code paths you missed during testing, so it's hard

// to know you got this right), so this is not recommended unless you

// really know what are doing, and need to optimize every bit of speed

// and size.

// The names in this list are names from the WebAssembly Names section. The

// wasm backend will emit those names in *human-readable* form instead of

// typical C++ mangling. For example, you should write Struct::func()

// instead of _ZN6Struct4FuncEv. C is also different from C++, as C

// names don't end with parameters; as a result foo(int) in C++ would appear

// as just foo in C (C++ has parameters because it needs to differentiate

// overloaded functions). You will see warnings in the console if a name in the

// list is missing (these are not errors because inlining etc. may cause

// changes which would mean a single list couldn't work for both -O0 and -O1

// builds, etc.). You can inspect the wasm binary to look for the actual names,

// either directly or using wasm-objdump or wasm-dis, etc.

// Simple '*' wildcard matching is supported.

var ASYNCIFY_REMOVE = [];

// Functions in the Asyncify add-list are added to the list of instrumented

// functions, that is, they will be instrumented even if otherwise asyncify

// thinks they don't need to be. As by default everything will be instrumented

// in the safest way possible, this is only useful if you use IGNORE_INDIRECT

// and use this list to fix up some indirect calls that *do* need to be

// instrumented.

// See notes on ASYNCIFY_REMOVE about the names.

var ASYNCIFY_ADD = [];

// If the Asyncify only-list is provided, then *only* the functions in the list

// will be instrumented. Like the remove-list, getting this wrong will break

// your application.

// See notes on ASYNCIFY_REMOVE about the names.

var ASYNCIFY_ONLY = [];

// Allows lazy code loading: where emscripten_lazy_load_code() is written, we

// will pause execution, load the rest of the code, and then resume.

var ASYNCIFY_LAZY_LOAD_CODE = 0;

// Runtime debug logging from asyncify internals.

var ASYNCIFY_DEBUG = 0;

// Runtime elements that are exported on Module by default. We used to export

// quite a lot here, but have removed them all, so this option is redundant

// given that EXTRA_EXPORTED_RUNTIME_METHODS exists, and so this option exists

// only for backwards compatibility. You should use

// EXTRA_EXPORTED_RUNTIME_METHODS for things you want to export from the

// runtime. Note that methods on this list are only exported if they are

// included (either automatically from linking, or due to being in

// DEFAULT_LIBRARY_FUNCS_TO_INCLUDE).

// Note that the name may be slightly misleading, as this is for any JS library

// element, and not just methods. For example, we can export the FS object by

// having "FS" in this list.

var EXPORTED_RUNTIME_METHODS = [];

// Additional methods to those in EXPORTED_RUNTIME_METHODS. Adjusting that list

// lets you remove methods that would be exported by default; setting values in

// this list lets you add to the default list without modifying it.

var EXTRA_EXPORTED_RUNTIME_METHODS = [];

// A list of incoming values on the Module object in JS that we care about. If

// a value is not in this list, then we don't emit code to check if you provide

// it on the Module object. For example, if

// you have this:

//

// var Module = {

// print: function(x) { console.log('print: ' + x) },

// preRun: [function() { console.log('pre run') }]

// };

//

// Then MODULE_JS_API must contain 'print' and 'preRun'; if it does not then

// we may not emit code to read and use that value. In other words, this

// option lets you set, statically at compile time, the list of which Module

// JS values you will be providing at runtime, so the compiler can better

// optimize.

//

// Setting this list to [], or at least a short and concise set of names you

// actually use, can be very useful for reducing code size. By default the

// list contains all the possible APIs.

//

// FIXME: should this just be 0 if we want everything?

var INCOMING_MODULE_JS_API = [

'ENVIRONMENT', 'GL_MAX_TEXTURE_IMAGE_UNITS', 'SDL_canPlayWithWebAudio',

'SDL_numSimultaneouslyQueuedBuffers', 'INITIAL_MEMORY', 'wasmMemory', 'arguments',

'buffer', 'canvas', 'doNotCaptureKeyboard', 'dynamicLibraries',

'elementPointerLock', 'extraStackTrace', 'forcedAspectRatio',

'instantiateWasm', 'keyboardListeningElement', 'freePreloadedMediaOnUse',

'locateFile', 'logReadFiles', 'mainScriptUrlOrBlob', 'mem',

'monitorRunDependencies', 'noExitRuntime', 'noInitialRun', 'onAbort',

'onCustomMessage', 'onExit', 'onFree', 'onFullScreen', 'onMalloc',

'onRealloc', 'onRuntimeInitialized', 'postMainLoop', 'postRun', 'preInit',

'preMainLoop', 'preRun',

'preinitializedWebGLContext', 'memoryInitializerRequest', 'preloadPlugins',

'print', 'printErr', 'quit', 'setStatus', 'statusMessage', 'stderr',

'stdin', 'stdout', 'thisProgram', 'wasm', 'wasmBinary', 'websocket'

];

// If set to nonzero, the provided virtual filesystem if treated

// case-insensitive, like Windows and macOS do. If set to 0, the VFS is

// case-sensitive, like on Linux.

var CASE_INSENSITIVE_FS = 0;

// If set to 0, does not build in any filesystem support. Useful if you are just

// doing pure computation, but not reading files or using any streams (including

// fprintf, and other stdio.h things) or anything related. The one exception is

// there is partial support for printf, and puts, hackishly. The compiler will

// automatically set this if it detects that syscall usage (which is static)

// does not require a full filesystem. If you still want filesystem support, use

// FORCE_FILESYSTEM

var FILESYSTEM = 1;

// Makes full filesystem support be included, even if statically it looks like

// it is not used. For example, if your C code uses no files, but you include

// some JS that does, you might need this.

var FORCE_FILESYSTEM = 0;

// Enables support for the NODERAWFS filesystem backend. This is a special

// backend as it replaces all normal filesystem access with direct Node.js

// operations, without the need to do `FS.mount()`, and this backend only

// works with Node.js. The initial working directory will be same as

// process.cwd() instead of VFS root directory. Because this mode directly uses

// Node.js to access the real local filesystem on your OS, the code will not

// necessarily be portable between OSes - it will be as portable as a Node.js

// program would be, which means that differences in how the underlying OS

// handles permissions and errors and so forth may be noticeable. This has

// mostly been tested on Linux so far.

var NODERAWFS = 0;

// This saves the compiled wasm module in a file with name

// $WASM_BINARY_NAME.$V8_VERSION.cached

// and loads it on subsequent runs. This caches the compiled wasm code from

// v8 in node, which saves compiling on subsequent runs, making them start up

// much faster.

// The V8 version used in node is included in the cache name so that we don't

// try to load cached code from another version, which fails silently (it seems

// to load ok, but we do actually recompile).

// * The only version known to work for sure is node 12.9.1, as this has

// regressed, see

// https://github.com/nodejs/node/issues/18265#issuecomment-622971547

// * The default location of the .cached files is alongside the wasm binary,

// as mentioned earlier. If that is in a read-only directory, you may need

// to place them elsewhere. You can use the locateFile() hook to do so.

var NODE_CODE_CACHING = 0;

// Functions that are explicitly exported. These functions are kept alive

// through LLVM dead code elimination, and also made accessible outside of the

// generated code even after running closure compiler (on "Module"). The

// symbols listed here require an `_` prefix.

//

// By default if this setting is not specified on the command line the

// `_main` function will be implicitly exported. In STANDALONE_WASM mode the

// default export is `__start` (or `__initialize` if --no-entry is specified).

var EXPORTED_FUNCTIONS = [];

// If true, we export all the symbols that are present in JS onto the Module

// object. This does not affect which symbols will be present - it does not

// prevent DCE or cause anything to be included in linking. It only does

// Module['X'] = X;

// for all X that end up in the JS file. This is useful to export the JS

// library functions on Module, for things like dynamic linking.

var EXPORT_ALL = 0;

// Remembers the values of these settings, and makes them accessible

// through Runtime.getCompilerSetting and emscripten_get_compiler_setting.

// To see what is retained, look for compilerSettings in the generated code.

var RETAIN_COMPILER_SETTINGS = 0;

// JS library elements (C functions implemented in JS) that we include by

// default. If you want to make sure something is included by the JS compiler,

// add it here. For example, if you do not use some emscripten_* C API call

// from C, but you want to call it from JS, add it here (and in EXPORTED

// FUNCTIONS with prefix "_", if you use closure compiler). Note that the name

// may be slightly misleading, as this is for any JS library element, and not

// just functions. For example, you can include the Browser object by adding

// "$Browser" to this list.

var DEFAULT_LIBRARY_FUNCS_TO_INCLUDE = [];

// This list is also used to determine auto-exporting of library dependencies

// (i.e., functions that might be dependencies of JS library functions, that if

// so we must export so that if they are implemented in C they will be

// accessible, in ASM_JS mode).

var LIBRARY_DEPS_TO_AUTOEXPORT = ['memcpy'];

// Include all JS library functions instead of the sum of

// DEFAULT_LIBRARY_FUNCS_TO_INCLUDE + any functions used by the generated code.

// This is needed when dynamically loading (i.e. dlopen) modules that make use

// of runtime library functions that are not used in the main module. Note that

// this only applies to js libraries, *not* C. You will need the main file to

// include all needed C libraries. For example, if a module uses malloc or new,

// you will need to use those in the main file too to pull in malloc for use by

// the module.

var INCLUDE_FULL_LIBRARY = 0;

// Set this to a string to override the shell file used

var SHELL_FILE = 0;

// If set to 1, we emit relocatable code from the LLVM backend; both

// globals and function pointers are all offset (by gb and fp, respectively)

// Automatically set for SIDE_MODULE or MAIN_MODULE.

var RELOCATABLE = 0;

// A main module is a file compiled in a way that allows us to link it to

// a side module using emlink.py.

// 1: Normal main module.

// 2: DCE'd main module. We eliminate dead code normally. If a side

// module needs something from main, it is up to you to make sure

// it is kept alive.

var MAIN_MODULE = 0;

// Corresponds to MAIN_MODULE (also supports modes 1 and 2)

var SIDE_MODULE = 0;

// If this is a shared object (MAIN_MODULE == 1 || SIDE_MODULE == 1), then we

// will link these at runtime. They must have been built with SIDE_MODULE == 1.

var RUNTIME_LINKED_LIBS = [];

// If set to 1, this is a worker library, a special kind of library that is run

// in a worker. See emscripten.h

var BUILD_AS_WORKER = 0;

// If set to 1, we build the project into a js file that will run in a worker,

// and generate an html file that proxies input and output to/from it.

var PROXY_TO_WORKER = 0;

// If set, the script file name the main thread loads. Useful if your project

// doesn't run the main emscripten- generated script immediately but does some

// setup before

var PROXY_TO_WORKER_FILENAME = '';

// If set to 1, compiles in a small stub main() in between the real main() which

// calls pthread_create() to run the application main() in a pthread. This is

// something that applications can do manually as well if they wish, this option

// is provided as convenience.

//

// The pthread that main() runs on is a normal pthread in all ways, with the one

// difference that its stack size is the same as the main thread would normally

// have, that is, TOTAL_STACK. This makes it easy to flip between

// PROXY_TO_PTHREAD and non-PROXY_TO_PTHREAD modes with main() always getting

// the same amount of stack.

//

// This proxies Module['canvas'], if present, and if OFFSCREEN_CANVAS support

// is enabled. This has to happen because this is the only chance - this browser

// main thread does the only pthread_create call that happens on

// that thread, so it's the only chance to transfer the canvas from there.

var PROXY_TO_PTHREAD = 0;

// If set to 1, this file can be linked with others, either as a shared library

// or as the main file that calls a shared library. To enable that, we will not

// internalize all symbols and cull the unused ones, in other words, we will not

// remove unused functions and globals, which might be used by another module we

// are linked with.

//

// MAIN_MODULE and SIDE_MODULE both imply this, so it not normally necessary

// to set this explicitly. Note that MAIN_MODULE and SIDE_MODULE mode 2 do

// *not* set this, so that we still do normal DCE on them, and in that case

// you must keep relevant things alive yourself using exporting.

var LINKABLE = 0;

// Emscripten 'strict' build mode: Drop supporting any deprecated build options.

// Set the environment variable EMCC_STRICT=1 or pass -s STRICT=1 to test that a

// codebase builds nicely in forward compatible manner.

// Changes enabled by this:

// * The C define EMSCRIPTEN is not defined (__EMSCRIPTEN__ always is, and

// is the correct thing to use).

// * STRICT_JS is enabled.

// * IGNORE_MISSING_MAIN is disabled.

// * AUTO_JS_LIBRARIES is disabled.

// * AUTO_ARCHIVE_INDEXES is disabled.

// * DEFAULT_TO_CXX is disabled.

// [compile+link]

var STRICT = 0;

// Allow program to link with or without `main` symbol.

// If this is disabled then one must provide a `main` symbol or explicitly

// opt out by passing `--no-entry` or an EXPORTED_FUNCTIONS list that doesn't

// include `_main`.

var IGNORE_MISSING_MAIN = 1;

// Automatically attempt to add archive indexes at link time to archives that

// don't already have them. This can happen when GNU ar or GNU ranlib is used

// rather than `llvm-ar` or `emar` since the former don't understand the wasm

// object format.

// [link]

var AUTO_ARCHIVE_INDEXES = 1;

// Add "use strict;" to generated JS

var STRICT_JS = 0;

// If set to 1, we will warn on any undefined symbols that are not resolved by

// the library_*.js files. Note that it is common in large projects to not

// implement everything, when you know what is not going to actually be called

// (and don't want to mess with the existing buildsystem), and functions might

// be implemented later on, say in --pre-js, so you may want to build with -s

// WARN_ON_UNDEFINED_SYMBOLS=0 to disable the warnings if they annoy you. See

// also ERROR_ON_UNDEFINED_SYMBOLS. Any undefined symbols that are listed in-

// EXPORTED_FUNCTIONS will also be reported.

var WARN_ON_UNDEFINED_SYMBOLS = 1;

// If set to 1, we will give a link-time error on any undefined symbols (see

// WARN_ON_UNDEFINED_SYMBOLS). To allow undefined symbols at link time set this

// to 0, in which case if an undefined function is called a runtime error will

// occur. Any undefined symbols that are listed in EXPORTED_FUNCTIONS will also

// be reported.

var ERROR_ON_UNDEFINED_SYMBOLS = 1;

// Use small chunk size for binary synchronous XHR's in Web Workers. Used for

// testing. See test_chunked_synchronous_xhr in runner.py and library.js.

var SMALL_XHR_CHUNKS = 0;

// If 1, will include shim code that tries to 'fake' a browser environment, in

// order to let you run a browser program (say, using SDL) in the shell.

// Obviously nothing is rendered, but this can be useful for benchmarking and

// debugging if actual rendering is not the issue. Note that the shim code is

// very partial - it is hard to fake a whole browser! - so keep your

// expectations low for this to work.

var HEADLESS = 0;

// If 1, we force Date.now(), Math.random, etc. to return deterministic results.

// This also tries to make execution deterministic across machines and

// environments, for example, not doing anything different based on the

// browser's language setting (which would mean you can get different results

// in different browsers, or in the browser and in node).

// Good for comparing builds for debugging purposes (and nothing else).

var DETERMINISTIC = 0;

// By default we emit all code in a straightforward way into the output

// .js file. That means that if you load that in a script tag in a web

// page, it will use the global scope. With `MODULARIZE` set, we instead emit

// the code wrapped in a function that returns a promise. The promise is

// resolved with the module instance when it is safe to run the compiled code,

// similar to the `onRuntimeInitialized` callback. You do not need to use the

// `onRuntimeInitialized` callback when using `MODULARIZE`.

//

// The default name of the function is `Module`, but can be changed using the

// `EXPORT_NAME` option. We recommend renaming it to a more typical name for a

// factory function, e.g. `createModule`.

//

//

// You use the factory function like so:

//

// const module = await EXPORT_NAME();

//

// or:

//

// let module;

// EXPORT_NAME().then(instance => {

// module = instance;

// });

//

//

// The factory function accepts 1 parameter, an object with default values for

// the module instance:

//

// const module = await EXPORT_NAME({ option: value, ... });

//

// Note the parentheses - we are calling EXPORT_NAME in order to instantiate

// the module. This allows you to create multiple instances of the module.

//

// Note that in MODULARIZE mode we do *not* look for a global `Module` object

// for default values. Default values must be passed as a parameter to the

// factory function.

//

// The default .html shell file provided in MINIMAL_RUNTIME mode will create

// a singleton instance automatically, to run the application on the page.

// (Note that it does so without using the Promise API mentioned earlier, and

// so code for the Promise is not even emitted in the .js file if you tell

// emcc to emit an .html output.)

// The default .html shell file provided by traditional runtime mode is only

// compatible with MODULARIZE=0 mode, so when building with traditional

// runtime, you should provided your own html shell file to perform the

// instantiation when building with MODULARIZE=1. (For more details, see

// https://github.com/emscripten-core/emscripten/issues/7950)

//

// If you add --pre-js or --post-js files, they will be included inside

// the factory function with the rest of the emitted code in order to be

// optimized together with it.

//