-
Notifications
You must be signed in to change notification settings - Fork 3.3k
/
settings.js
694 lines (617 loc) · 48.1 KB
/
settings.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
//
// Various compiling-to-JS parameters. 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..]
//
// See https://github.com/kripken/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.
//
// Tuning
var QUANTUM_SIZE = 4; // This is the size of an individual field in a structure. 1 would
// lead to e.g. doubles and chars both taking 1 memory address. This
// is a form of 'compressed' memory, with shrinking and stretching
// according to the type, when compared to C/C++. On the other hand
// the normal value of 4 means all fields take 4 memory addresses,
// as per the norm on a 32-bit machine.
//
// Changing this from the default of 4 is deprecated.
var ASSERTIONS = 1; // 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
var VERBOSE = 0; // When set to 1, will generate more verbose output during compilation.
var INVOKE_RUN = 1; // 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 NO_EXIT_RUNTIME = 0; // If set, the runtime is not quit when main() completes (allowing code to
// run afterwards, for example from the browser main event loop).
var MEM_INIT_METHOD = 0; // How to represent the initial memory content.
// 0: keep array 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
// XXX this is known to have bugs on windows, see https://github.com/kripken/emscripten/pull/3326
var TOTAL_STACK = 5*1024*1024; // 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_MEMORY = 16777216; // The total 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.
var ABORTING_MALLOC = 1; // 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 (TOTAL_MEMORY) must be.
// If you set this to 0, then you get the standard malloc behavior of
// returning NULL (0) when it fails.
var ALLOW_MEMORY_GROWTH = 0; // If false, we abort with an error if we try to allocate more memory than
// we can (TOTAL_MEMORY). If true, we will grow the memory arrays at
// runtime, seamlessly and dynamically. This has a performance cost though,
// 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).
// See https://code.google.com/p/v8/issues/detail?id=3907 regarding
// memory growth performance in chrome.
// 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 GLOBAL_BASE = -1; // where global data begins; the start of static memory. -1 means use the
// default, any other value will be used as an override
// Code embetterments
var DOUBLE_MODE = 1; // How to load and store 64-bit doubles.
// A potential risk is that doubles may be only 32-bit aligned. Forcing 64-bit alignment
// in Clang itself should be able to solve that, or as a workaround in DOUBLE_MODE 1 we
// will carefully load in parts, in a way that requires only 32-bit alignment. In DOUBLE_MODE
// 0 we will simply store and load doubles as 32-bit floats, so when they are stored/loaded
// they will truncate from 64 to 32 bits, and lose precision. This is faster, and might
// work for some code (but probably that code should just use floats and not doubles anyhow).
// Note that a downside of DOUBLE_MODE 1 is that we currently store the double in parts,
// then load it aligned, and that load-store will make JS engines alter it if it is being
// stored to a typed array for security reasons. That will 'fix' the number from being a
// NaN or an infinite number.
var UNALIGNED_MEMORY = 0; // If enabled, all memory accesses are assumed to be unaligned. In unaligned memory mode,
// you can run nonportable code that typically would break in JS (or on ARM for that
// matter, which also cannot do unaligned reads/writes), at the cost of slowness
var FORCE_ALIGNED_MEMORY = 0; // If enabled, assumes all reads and writes are fully aligned for the type they
// use. This is true in proper C code (no undefined behavior), but is sadly
// common enough that we can't do it by default. See SAFE_HEAP.
// for ways to help find places in your code where unaligned reads/writes are done -
// you might be able to refactor your codebase to prevent them, which leads to
// smaller and faster code, or even the option to turn this flag on.
var WARN_UNALIGNED = 0; // 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.
var PRECISE_I64_MATH = 1; // If enabled, i64 addition etc. is emulated - which is slow but precise. If disabled,
// we use the 'double trick' which is fast but incurs rounding at high values.
// If set to 2, we always include the i64 math code, which is necessary in the case
// that we can't know at compile time that 64-bit math is needed. For example, if you
// print 64-bit values with printf, but never add them, we can't know at compile time
// and you need to set this to 2.
var PRECISE_F32 = 0; // 0: Use JS numbers for floating-point values. These are 64-bit and do not model C++
// floats exactly, which are 32-bit.
// 1: Model C++ floats precisely, using Math.fround, polyfilling when necessary. This
// can be slow if the polyfill is used on heavy float32 computation. See note on
// browser support below.
// 2: Model C++ floats precisely using Math.fround if available in the JS engine, otherwise
// use an empty polyfill. This will have much less of a speed penalty than using the full
// polyfill in cases where engine support is not present. In addition, we can
// remove the empty polyfill calls themselves on the client when generating html,
// which should mean that this gives you the best of both worlds of 0 and 1, and is
// therefore recommended, *unless* you need a guarantee of proper float32 precision
// (in that case, use option 1).
// XXX Note: To optimize float32-using code, we use the 'const' keyword in the emitted
// code. This allows us to avoid unnecessary calls to Math.fround, which would
// slow down engines not yet supporting that function. 'const' is present in
// all modern browsers, including Firefox, Chrome and Safari, but in IE is only
// present in IE11 and above. Therefore if you need to support legacy versions of
// IE, you should not enable PRECISE_F32 1 or 2.
var SIMD = 0; // Whether to allow autovectorized SIMD code ( https://github.com/johnmccutchan/ecmascript_simd ).
// SIMD intrinsics are always compiled to SIMD code, so you only need this option if you
// also want the autovectorizer to run.
// Note that SIMD support in browsers is not yet there (as of Sep 2, 2014), so you will be
// running in a polyfill, which is not fast.
var USE_CLOSURE_COMPILER = 0; // Whether closure compiling is being run on this output
var SKIP_STACK_IN_SMALL = 1; // When enabled, does not push/pop the stack at all in
// functions that have no basic stack usage. But, they
// may allocate stack later, and in a loop, this can be
// very bad. In particular, when debugging, printf()ing
// a lot can exhaust the stack very fast, with this option.
// In particular, be careful with the autodebugger! (We do turn
// this off automatically in that case, though.)
var INLINING_LIMIT = 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
var OUTLINING_LIMIT = 0; // A function size above which we try to automatically break up
// functions into smaller ones, to avoid the downsides of very
// large functions (JS engines often compile them very slowly,
// compile them with lower optimizations, or do not optimize them
// at all). If 0, we do not perform outlining at all.
// To see which funcs are large, you can inspect the source
// in a debug build (-g2 or -g for example), and can run
// tools/find_bigfuncs.py on that to get a sorted list by size.
// Another possibility is to look in the web console in firefox,
// which will note slowly-compiling functions.
// You will probably want to experiment with various values to
// see the impact on compilation time, code size and runtime
// throughput. It is hard to say what values to start testing
// with, but something around 20,000 to 100,000 might make sense.
// (The unit size is number of AST nodes.)
// Outlining decreases maximum function size, but does so at the
// cost of increasing overall code size as well as performance
// (outlining itself makes code less optimized, and requires
// emscripten to disable some passes that are incompatible with
// it).
var AGGRESSIVE_VARIABLE_ELIMINATION = 0; // Run aggressiveVariableElimination in js-optimizer.js
var SIMPLIFY_IFS = 1; // Whether to simplify ifs in js-optimizer.js
// Generated code debugging options
var SAFE_HEAP = 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 preamble.js for the actual checks performed.
var SAFE_HEAP_LOG = 0; // Log out all SAFE_HEAP operations
var RESERVED_FUNCTION_POINTERS = 0; // In asm.js mode, we cannot simply add function pointers to
// function tables, so we reserve some slots for them. An
// alternative to this is to use EMULATED_FUNCTION_POINTERS,
// in which case we don't need to reserve.
var ALIASING_FUNCTION_POINTERS = 0; // Whether to allow function pointers to alias if they have
// a different type. This can greatly decrease table sizes
// in asm.js, but can break code that compares function
// pointers across different types.
var EMULATED_FUNCTION_POINTERS = 0; // By default we implement function pointers using asm.js
// function tables, which is very fast. With this option,
// we implement them more flexibly by emulating them: we
// call out into JS, which handles the function tables.
// 1: Full emulation. This means you can modify the
// table in JS fully dynamically, not just add to
// the end.
// 2: Optimized emulation. Assumes once something is
// added to the table, it will not change. This allows
// dynamic linking while keeping performance fast,
// as we can do a fast call into the internal table
// if the fp is in the right range. Shared modules
// (MAIN_MODULE, SIDE_MODULE) do this by default.
// This requires RELOCATABLE to be set.
var EMULATE_FUNCTION_POINTER_CASTS = 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.
var FUNCTION_POINTER_ALIGNMENT = 2; // Byte alignment of function pointers - we will fill the
// tables with zeros on aligned values. 1 means all values
// are aligned and all will be used (which is optimal).
// Sadly 1 breaks on &Class::method function pointer calls,
// which llvm assumes have the lower bit zero (see
// test_polymorph and issue #1692).
var EXCEPTION_DEBUG = 0; // Print out exceptions in emscriptened code. Does not work in asm.js mode
var DEMANGLE_SUPPORT = 0; // If 1, build in libcxxabi's full c++ demangling code, to allow stackTrace()
// to emit fully proper demangled c++ names
var LIBRARY_DEBUG = 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 SYSCALL_DEBUG = 0; // Print out all syscalls
var SOCKET_DEBUG = 0; // Log out socket/network data transfer.
var SOCKET_WEBRTC = 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'};
// Run time configuration may be useful as it lets an application select multiple different services.
var WEBSOCKET_URL = 'ws://'; // 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_SUBPROTOCOL = 'binary'; // A string containing a comma separated list of WebSocket subprotocols
// as would be present in the Sec-WebSocket-Protocol header.
var OPENAL_DEBUG = 0; // Print out debugging information from our OpenAL implementation.
var GL_ASSERTIONS = 0; // Adds extra checks for error situations in the GL library. Can impact performance.
var GL_DEBUG = 0; // Print out all calls into WebGL. As with LIBRARY_DEBUG, you can set a runtime
// option, in this case GL.debug.
var GL_TESTING = 0; // When enabled, sets preserveDrawingBuffer in the context, to allow tests to work (but adds overhead)
var GL_MAX_TEMP_BUFFER_SIZE = 2097152; // How large GL emulation temp buffers are
var GL_UNSAFE_OPTS = 1; // Enables some potentially-unsafe optimizations in GL emulation code
var FULL_ES2 = 0; // Forces support for all GLES2 features, not just the WebGL-friendly subset.
var USE_WEBGL2 = 0; // Enables WebGL2 native functions. This mode will also create a WebGL2
// context by default if no version is specified.
var FULL_ES3 = 0; // Forces support for all GLES3 features, not just the WebGL2-friendly subset.
var LEGACY_GL_EMULATION = 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 GL_FFP_ONLY = 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 STB_IMAGE = 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 LZ4 = 0; // 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 DISABLE_EXCEPTION_CATCHING = 0; // Disables generating code to actually catch exceptions. If the code you
// are compiling does not actually rely on catching exceptions (but the
// compiler generates code for it, maybe because of stdlibc++ stuff),
// then this can make it much faster. If an exception actually happens,
// it will not be caught and the program will halt (so this will not
// introduce silent failures, which is good).
// 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 whitelist
// TODO: Make this also remove cxa_begin_catch etc., optimize relooper
// for it, etc. (perhaps do all of this as preprocessing on .ll?)
var EXCEPTION_CATCHING_WHITELIST = []; // Enables catching exception in the listed functions only, if
// DISABLE_EXCEPTION_CATCHING = 2 is set
// For more explanations of this option, please visit
// https://github.com/kripken/emscripten/wiki/Asyncify
var ASYNCIFY = 0; // Whether to enable asyncify transformation
// This allows to inject some async functions to the C code that appear to be sync
// e.g. emscripten_sleep
var ASYNCIFY_FUNCTIONS = ['emscripten_sleep', // Functions that call any function in the list, directly or indirectly
'emscripten_wget', // will be transformed
'emscripten_yield'];
var ASYNCIFY_WHITELIST = ['qsort', // Functions in this list are never considered async, even if they appear in ASYNCIFY_FUNCTIONS
'trinkle', // In the asyncify transformation, any function that calls a function pointer is considered async
'__toread', // This whitelist is useful when a function is known to be sync
'__uflow', // currently this link contains some functions in libc
'__fwritex',
'MUSL_vfprintf'];
var EXPORTED_RUNTIME_METHODS = [ // Methods that are exported on Module. By default we export quite a bit, you can reduce this list to lower your code size,
// especially when closure is run (exporting prevents closure from eliminating code)
// 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)
'FS_createFolder',
'FS_createPath',
'FS_createDataFile',
'FS_createPreloadedFile',
'FS_createLazyFile',
'FS_createLink',
'FS_createDevice',
'FS_unlink',
'Runtime',
'ccall',
'cwrap',
'setValue',
'getValue',
'ALLOC_NORMAL',
'ALLOC_STACK',
'ALLOC_STATIC',
'ALLOC_DYNAMIC',
'ALLOC_NONE',
'allocate',
'getMemory',
'Pointer_stringify',
'AsciiToString',
'stringToAscii',
'UTF8ArrayToString',
'UTF8ToString',
'stringToUTF8Array',
'stringToUTF8',
'lengthBytesUTF8',
'stackTrace',
'addOnPreRun',
'addOnInit',
'addOnPreMain',
'addOnExit',
'addOnPostRun',
'intArrayFromString',
'intArrayToString',
'writeStringToMemory',
'writeArrayToMemory',
'writeAsciiToMemory',
'addRunDependency',
'removeRunDependency',
];
var EXTRA_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 FS_LOG = 0; // Log all FS operations. This is especially helpful when you're porting
// a new project and want to see a list of file system operations happening
// so that you can create a virtual file system with all of the required files.
var CASE_INSENSITIVE_FS = 0; // If set to nonzero, the provided virtual filesystem if treated case-insensitive, like
// Windows and OSX do. If set to 0, the VFS is case-sensitive, like on Linux.
var MEMFS_APPEND_TO_TYPED_ARRAYS = 0; // If set to nonzero, MEMFS will always utilize typed arrays as the backing store
// for appending data to files. The default behavior is to use typed arrays for files
// when the file size doesn't change after initial creation, and for files that do
// change size, use normal JS arrays instead.
var NO_FILESYSTEM = 0; // If set, 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 FORCE_FILESYSTEM = 0; // 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 EXPORTED_FUNCTIONS = ['_main'];
// 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").
// Note the necessary prefix of "_".
// Note also that this is the full list of exported functions - if you
// have a main() function and want it to run, you must include it in this
// list (as _main is by default in this value, and if you override it
// without keeping it there, you are in effect removing it).
var EXPORT_ALL = 0; // If true, we export all the symbols. Note that this does *not* affect LLVM, so it can
// still eliminate functions as dead. This just exports them on the Module object.
var EXPORT_BINDINGS = 0; // Export all bindings generator functions (prefixed with emscripten_bind_). This
// is necessary to use the WebIDL binder or bindings generator with asm.js
var EXPORT_FUNCTION_TABLES = 0; // If true, export all the functions appearing in a function table, and the
// tables themselves.
var RETAIN_COMPILER_SETTINGS = 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 EMSCRIPTEN_VERSION = ''; // this will contain the emscripten version. you should not modify it. This
// and the following few settings are useful in combination with
// RETAIN_COMPILER_SETTINGS
var OPT_LEVEL = 0; // this will contain the optimization level (-Ox). you should not modify it.
var DEBUG_LEVEL = 0; // this will contain the debug level (-gx). you should not modify it.
// JS library functions (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).
var DEFAULT_LIBRARY_FUNCS_TO_INCLUDE = ['memcpy', 'memset', 'malloc', 'free'];
var LIBRARY_DEPS_TO_AUTOEXPORT = ['memcpy']; // 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 INCLUDE_FULL_LIBRARY = 0; // 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 dlmalloc
// for use by the module.
var SHELL_FILE = 0; // set this to a string to override the shell file used
var RELOCATABLE = 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)
var MAIN_MODULE = 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 SIDE_MODULE = 0; // Corresponds to MAIN_MODULE
var RUNTIME_LINKED_LIBS = []; // If this is a main module (MAIN_MODULE == 1), then
// we will link these at runtime. They must have been built with
// SIDE_MODULE == 1.
var BUILD_AS_SHARED_LIB = 0; // (deprecated option TODO: remove)
var BUILD_AS_WORKER = 0; // If set to 1, this is a worker library, a special kind of library
// that is run in a worker. See emscripten.h
var PROXY_TO_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_FILENAME = ''; // 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 LINKABLE = 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.
// BUILD_AS_SHARED_LIB > 0 implies this, so it is only important to set this to 1
// when building the main file, and *if* that main file has symbols that
// the library it will open will then access through an extern.
// LINKABLE of 0 is very useful in that we can reduce the size of the
// generated code very significantly, by removing everything not actually used.
var WARN_ON_UNDEFINED_SYMBOLS = 1; // 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
var ERROR_ON_UNDEFINED_SYMBOLS = 0; // If set to 1, we will give a compile-time error on any
// undefined symbols (see WARN_ON_UNDEFINED_SYMBOLS).
var SMALL_XHR_CHUNKS = 0; // 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 HEADLESS = 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 DETERMINISTIC = 0; // If 1, we force Date.now(), Math.random, etc. to return deterministic
// results. Good for comparing builds for debugging purposes (and nothing else)
var MODULARIZE = 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 will instead emit
//
// var EXPORT_NAME = function(Module) {
// Module = Module || {};
// // .. all the emitted code from emscripten ..
// return Module;
// };
//
// where EXPORT_NAME is from the option of the same name (so, by default
// it will be var Module = ..., and so you should change EXPORT_NAME if
// you want more than one module in the same web page).
//
// You can then use this by something like
//
// var instance = EXPORT_NAME();
//
// or
//
// var instance = EXPORT_NAME({ option: value, ... });
//
// Note the parentheses - we are calling EXPORT_NAME in order to instantiate
// the module. (This allows, in particular, for you to create multiple
// instantiations, etc.)
var BENCHMARK = 0; // If 1, will just time how long main() takes to execute, and not
// print out anything at all whatsoever. This is useful for benchmarking.
var ASM_JS = 1; // If 1, generate code in asm.js format. If 2, emits the same code except
// for omitting 'use asm'
var FINALIZE_ASM_JS = 1; // If 1, will finalize the final emitted code, including operations
// that prevent later js optimizer passes from running, like
// converting +5 into 5.0 (the js optimizer sees 5.0 as just 5).
var SWAPPABLE_ASM_MODULE = 0; // If 1, then all exports from the asm.js module will be accessed
// indirectly, which allow the asm module to be swapped later.
// Note: It is very important to build the two modules that
// are to be swapped with the same optimizations and so forth,
// as we depend on them being a drop-in replacement for each
// other (same globals on the heap at the same locations, etc.)
var SEPARATE_ASM = 0; // see emcc --separate-asm
var ONLY_MY_CODE = 0; // This disables linking and other causes of adding extra code
// automatically, and as a result, your output compiled code
// (in the .asm.js file, if you emit with --separate-asm) will
// contain only the functions you provide.
var PGO = 0; // Enables profile-guided optimization in the form of runtime checks for
// which functions are actually called. Emits a list during shutdown that you
// can pass to DEAD_FUNCTIONS (you can also emit the list manually by
// calling PGOMonitor.dump());
var DEAD_FUNCTIONS = []; // Functions on this list are not converted to JS, and calls to
// them are turned into abort()s. This is potentially useful for
// reducing code size.
// If a dead function is actually called, you will get a runtime
// error.
// This can affect both functions in compiled code, and system
// library functions (e.g., you can use this to kill printf).
// TODO: options to lazily load such functions
var EXPLICIT_ZEXT = 0; // If 1, generate an explicit conversion of zext i1 to i32, using ?:
var EXPORT_NAME = 'Module'; // Global variable to export the module as for environments without a standardized module
// loading system (e.g. the browser and SM shell).
var NO_DYNAMIC_EXECUTION = 0; // When set to 1, we do not emit eval() and new Function(), which disables some functionality
// (causing runtime errors if attempted to be used), but allows the emitted code to be
// acceptable in places that disallow dynamic code execution (chrome packaged app,
// privileged firefox app, etc.). Pass this flag when developing an Emscripten application
// that is targeting a privileged or a certified execution environment, see
// Firefox Content Security Policy (CSP) webpage for details:
// https://developer.mozilla.org/en-US/Apps/Build/Building_apps_for_Firefox_OS/CSP
// When this flag is set, the following features (linker flags) are unavailable:
// --closure 1: When using closure compiler, eval() would be needed to locate the Module object.
// -s RELOCATABLE=1: the function Runtime.loadDynamicLibrary would need to eval().
// --bind: Embind would need to eval().
// Additionally, the following Emscripten runtime functions are unavailable when
// NO_DYNAMIC_EXECUTION=1 is set, and an attempt to call them will throw an exception:
// - emscripten_run_script(),
// - emscripten_run_script_int(),
// - emscripten_run_script_string(),
// - dlopen(),
// - the functions ccall() and cwrap() are still available, but they are restricted to only
// being able to call functions that have been exported in the Module object in advance.
// When set to -s NO_DYNAMIC_EXECUTION=2 flag is set, attempts to call to eval() are demoted
// to warnings instead of throwing an exception.
var EMTERPRETIFY = 0; // Runs tools/emterpretify on the compiler output
var EMTERPRETIFY_FILE = ''; // If defined, a file to write bytecode to, otherwise the default is to embed it in text JS arrays (which is less efficient).
// When emitting HTML, we automatically generate code to load this file and set it to Module.emterpreterFile. If you
// emit JS, you need to make sure that Module.emterpreterFile contains an ArrayBuffer with the bytecode, when the code loads.
// Note: You might need to quote twice in the shell, something like -s 'EMTERPRETIFY_FILE="waka"'
var EMTERPRETIFY_BLACKLIST = []; // Functions to not emterpret, that is, to run normally at full speed
var EMTERPRETIFY_WHITELIST = []; // If this contains any functions, then only the functions in this list
// are emterpreted (as if all the rest are blacklisted; this overrides the BLACKLIST)
var EMTERPRETIFY_ASYNC = 0; // Allows sync code in the emterpreter, by saving the call stack, doing an async delay, and resuming it
var EMTERPRETIFY_ADVISE = 0; // Performs a static analysis to suggest which functions should be run in the emterpreter, as it
// appears they can be on the stack when a sync function is called in the EMTERPRETIFY_ASYNC option.
// After showing the suggested list, compilation will halt. You can apply the provided list as an
// emcc argument when compiling later.
var SPLIT_MEMORY = 0; // If > 0, we split memory into chunks, of the size given in this parameter.
// * TOTAL_MEMORY becomes the maximum amount of memory, as chunks are allocated on
// demand. That means this achieves a result similar to ALLOW_MEMORY_GROWTH, but
// better since it can free chunks in the middle. You still to set
// ALLOW_MEMORY_GROWTH if you want memory to grow beyond the initial TOTAL_MEMORY
// target.
// * Larger SPLIT_MEMORY sizes are generally faster to run.
// TODO: more docs
// TODO: add malloc-split to embuilder
var SAFE_SPLIT_MEMORY = 0; // Similar to SAFE_HEAP, but for SPLIT_MEMORY.
var RUNNING_JS_OPTS = 0; // whether js opts will be run, after the main compiler
var BOOTSTRAPPING_STRUCT_INFO = 0; // whether we are in the generate struct_info bootstrap phase
var EMSCRIPTEN_TRACING = 0; // Add some calls to emscripten tracing APIs
var USE_GLFW = 2; // Specify the GLFW version that is being linked against.
// Only relevant, if you are linking against the GLFW library.
// Valid options are 2 for GLFW2 and 3 for GLFW3.
var BINARYEN = ""; // Path to [Binaryen](https://github.com/WebAssembly/binaryen), which we use to
// compile (at runtime) our asm.js output into WebAssembly. That then runs in
// a shipped Binaryen interpreter for WebAssembly, or, once browsers get native
// WebAssembly support, it will run directly.
// This path should be to the root Binaryen directory (not the /bin subfolder).
// You need to build Binaryen, so that /bin/wasm.js under the Binaryen
// directory exists.
var BINARYEN_METHOD = ""; // See binaryen's src/js/post.js for details.
var WASM_BACKEND = 0; // Whether to use the WebAssembly backend that is in development in LLVM.
// This requires that BINARYEN be set, as we use Binaryen's s2wasm to
// translate the backend output.
// Ports
var USE_SDL = 1; // Specify the SDL version that is being linked against.
// 1, the default, is 1.3, which is implemented in JS
// 2 is a port of the SDL C code on emscripten-ports
var USE_SDL_IMAGE = 1; // Specify the SDL_image version that is being linked against. Must match USE_SDL
var USE_SDL_TTF = 1; // Specify the SDL_ttf version that is being linked against. Must match USE_SDL
var USE_ZLIB = 0; // 1 = use zlib from emscripten-ports
var USE_LIBPNG = 0; // 1 = use libpng from emscripten-ports
var USE_BULLET = 0; // 1 = use bullet from emscripten-ports
var USE_VORBIS = 0; // 1 = use vorbis from emscripten-ports
var USE_OGG = 0; // 1 = use ogg from emscripten-ports
var USE_FREETYPE = 0; // 1 = use freetype from emscripten-ports
var SDL2_IMAGE_FORMATS = []; // Formats to support in SDL2_image. Valid values: bmp, gif, lbm, pcx, png, pnm, tga, xcf, xpm, xv
// Compiler debugging options
var DEBUG_TAGS_SHOWING = [];
// Some useful items:
// framework
// frameworkLines
// gconst
// types
// vars
// unparsedFunctions
// metadata
// legalizer
// For internal use only
var ORIGINAL_EXPORTED_FUNCTIONS = [];
// The list of defines (C_DEFINES) was moved into struct_info.json in the same directory.
// That file is automatically parsed by tools/gen_struct_info.py.
// If you modify the headers, just clear your cache and emscripten libc should see
// the new values.
var IN_TEST_HARNESS = 0; // If true, the current build is performed for the Emscripten test harness.
var USE_PTHREADS = 0; // If true, enables support for pthreads.
var PTHREAD_POOL_SIZE = 0; // Specifies the number of web workers that are preallocated before runtime is initialized. If 0, workers are created on demand.
// Specifies the value returned by the function emscripten_num_logical_cores()
// if navigator.hardwareConcurrency is not supported. Pass in a negative number
// to show a popup dialog at startup so the user can configure this dynamically.
var PTHREAD_HINT_NUM_CORES = 4;
var PTHREADS_PROFILING = 0; // True when building with --threadprofiler
var MAX_GLOBAL_ALIGN = -1; // received from the backend
// Duplicate function elimination. This coalesces function bodies that are
// identical, which can happen e.g. if two methods have different C/C++
// or LLVM types, but end up identical at the asm.js level (all pointers
// are the same as int32_t in asm.js, for example).
// This option is quite slow to run, as it processes and hashes all methods
// in the codebase in multiple passes.
var ELIMINATE_DUPLICATE_FUNCTIONS = 0; // disabled by default
var ELIMINATE_DUPLICATE_FUNCTIONS_PASSES = 5;
var ELIMINATE_DUPLICATE_FUNCTIONS_DUMP_EQUIVALENT_FUNCTIONS = 0;
// Reserved: variables containing POINTER_MASKING.