diff options
| author | Haneef Mubarak <haneefmubarak@users.noreply.github.com> | 2014-02-24 22:48:14 -0800 |
|---|---|---|
| committer | Haneef Mubarak <haneefmubarak@users.noreply.github.com> | 2014-02-24 22:48:14 -0800 |
| commit | d2b63fabfb32bcc5b80c4d5febab486a20afb175 (patch) | |
| tree | 62f1c8b0c8c99270690546065eee78aa05995f62 | |
| parent | d09166ab48c96393edd06f89a2f928073d18586d (diff) | |
Revert "readme: hard tabs, comment shifting"
This reverts commit b0bc4b4525f850563dda14b3412795bb82441c8a.
altering `emcc` this strongly will break many other pulls
and will cause a nightmare in terms of merging
| -rwxr-xr-x | emcc | 3437 |
1 files changed, 1694 insertions, 1743 deletions
@@ -12,21 +12,21 @@ use emar, emranlib etc. instead of the same command without 'em'. Example uses: - For configure, instead of ./configure, cmake, etc., run emconfigure.py - with that command as an argument, for example + * For configure, instead of ./configure, cmake, etc., run emconfigure.py + with that command as an argument, for example - emconfigure.py ./configure [options] + emconfigure.py ./configure [options] - emconfigure.py is a tiny script that just sets some environment vars - as a convenience. The command just shown is equivalent to + emconfigure.py is a tiny script that just sets some environment vars + as a convenience. The command just shown is equivalent to - EMMAKEN_JUST_CONFIGURE=1 RANLIB=PATH/emranlib AR=PATH/emar CXX=PATH/em++ CC=PATH/emcc ./configure [options] + EMMAKEN_JUST_CONFIGURE=1 RANLIB=PATH/emranlib AR=PATH/emar CXX=PATH/em++ CC=PATH/emcc ./configure [options] - where PATH is the path to this file. + where PATH is the path to this file. - EMMAKEN_JUST_CONFIGURE tells emcc that it is being run in ./configure, - so it should relay everything to gcc/g++. You should not define that when - running make, of course. + EMMAKEN_JUST_CONFIGURE tells emcc that it is being run in ./configure, + so it should relay everything to gcc/g++. You should not define that when + running make, of course. After setting that up, run your build system normally. @@ -35,16 +35,16 @@ for the C++ compiler. This is needed for cases where we get a C++ file with a C extension, in which case CMake can be told to run g++ on it despite the .c extension, see - https://github.com/kripken/emscripten/issues/6 + https://github.com/kripken/emscripten/issues/6 (If a similar situation occurs with ./configure, you can do the same there too.) emcc can be influenced by a few environment variables: - EMMAKEN_NO_SDK - Will tell emcc *not* to use the emscripten headers. Instead - your system headers will be used. + EMMAKEN_NO_SDK - Will tell emcc *not* to use the emscripten headers. Instead + your system headers will be used. - EMMAKEN_COMPILER - The compiler to be used, if you don't want the default clang. + EMMAKEN_COMPILER - The compiler to be used, if you don't want the default clang. ''' import os, sys, shutil, tempfile, subprocess, shlex, time, re, logging, json @@ -53,7 +53,7 @@ from tools import shared, jsrun, system_libs from tools.shared import Compression, execute, suffix, unsuffixed, unsuffixed_basename, WINDOWS from tools.response_file import read_response_file -# endings = dot + a suffix, safe to test by filename.endswith(endings) +# endings = dot + a suffix, safe to test by filename.endswith(endings) C_ENDINGS = ('.c', '.C') CXX_ENDINGS = ('.cpp', '.cxx', '.cc', '.CPP', '.CXX', '.CC') OBJC_ENDINGS = ('.m',) @@ -74,29 +74,26 @@ JS_CONTAINING_SUFFIXES = ('js', 'html') # llvm opt level 3, and speed-wise emcc level 2 is already the slowest/most optimizing # level) LLVM_OPT_LEVEL = { - 0: 0, - 1: 1, - 2: 3, - 3: 3, + 0: 0, + 1: 1, + 2: 3, + 3: 3, } DEBUG = os.environ.get('EMCC_DEBUG') if DEBUG == "0": - DEBUG = None + DEBUG = None TEMP_DIR = os.environ.get('EMCC_TEMP_DIR') -LEAVE_INPUTS_RAW = os.environ.get('EMCC_LEAVE_INPUTS_RAW') # Do not compile .ll files into .bc, just compile them with emscripten directly - # Not recommended, this is mainly for the test runner, or if you have some other - # specific need. - - # One major limitation with this mode is that libc and libc++ cannot be - # added in. Also, LLVM optimizations will not be done, nor dead code elimination - -AUTODEBUG = os.environ.get('EMCC_AUTODEBUG') # If set to 1, we will run the autodebugger (the automatic debugging tool, see tools/autodebugger). - # Note that this will disable inclusion of libraries. This is useful because including - # dlmalloc makes it hard to compare native and js builds - -EMCC_CFLAGS = os.environ.get('EMCC_CFLAGS') # Additional compiler flags that we treat as if they were passed to us on the commandline +LEAVE_INPUTS_RAW = os.environ.get('EMCC_LEAVE_INPUTS_RAW') # Do not compile .ll files into .bc, just compile them with emscripten directly + # Not recommended, this is mainly for the test runner, or if you have some other + # specific need. + # One major limitation with this mode is that libc and libc++ cannot be + # added in. Also, LLVM optimizations will not be done, nor dead code elimination +AUTODEBUG = os.environ.get('EMCC_AUTODEBUG') # If set to 1, we will run the autodebugger (the automatic debugging tool, see tools/autodebugger). + # Note that this will disable inclusion of libraries. This is useful because including + # dlmalloc makes it hard to compare native and js builds +EMCC_CFLAGS = os.environ.get('EMCC_CFLAGS') # Additional compiler flags that we treat as if they were passed to us on the commandline logging.debug('invocation: ' + ' '.join(sys.argv) + (' + ' + EMCC_CFLAGS if EMCC_CFLAGS else '')) if EMCC_CFLAGS: sys.argv.append(EMCC_CFLAGS) @@ -111,462 +108,440 @@ shared.check_sanity(force=DEBUG) # Handle some global flags if len(sys.argv) == 1: - logging.warning('no input files') - exit(1) + logging.warning('no input files') + exit(1) # read response files very early on response_file = True while response_file: - response_file = None - for index in range(1, len(sys.argv)): - if sys.argv[index][0] == '@': - # found one, loop again next time - response_file = True - extra_args = read_response_file(sys.argv[index]) - - # slice in extra_args in place of the response file arg - sys.argv[index:index+1] = extra_args - break + response_file = None + for index in range(1, len(sys.argv)): + if sys.argv[index][0] == '@': + # found one, loop again next time + response_file = True + extra_args = read_response_file(sys.argv[index]) + # slice in extra_args in place of the response file arg + sys.argv[index:index+1] = extra_args + break if len(sys.argv) == 1 or '--help' in sys.argv: - this = os.path.basename('em++' if os.environ.get('EMMAKEN_CXX') else 'emcc') + this = os.path.basename('em++' if os.environ.get('EMMAKEN_CXX') else 'emcc') - print '''%s [options] file... + print '''%s [options] file... Most normal gcc/g++ options will work, for example: - --help Display this information - --version Display compiler version information + --help Display this information + --version Display compiler version information Options that are modified or new in %s include: - -O0 No optimizations (default). This is the recommended - setting for starting to port a project, as it - includes various assertions. - - -O1 Simple optimizations, including asm.js, LLVM -O1 - optimizations, relooping, and no runtime assertions - or C++ exception catching (to re-enable - C++ exception catching, use - -s DISABLE_EXCEPTION_CATCHING=0 ), and enables - - -s ALIASING_FUNCTION_POINTERS=1 - - This is the recommended setting when you want a - reasonably optimized build that is generated as - quickly as possible (it builds much faster than -O2). - - (Note: for details on the affects of different - opt levels, see apply_opt_level() in - tools/shared.py and also src/settings.js.) - - -O2 As -O1, plus various js-level optimizations and - LLVM -O3 optimizations. This is the recommended - setting for a release build: slower compilation - time in return for the smallest and fastest - output. - - -O3 As -O2, plus additional optimizations that can - take a significant amount of compilation time and/or - are relatively new. - - For tips on optimizing your code, see - https://github.com/kripken/emscripten/wiki/Optimizing-Code - - -s OPTION=VALUE JavaScript code generation option passed - into the emscripten compiler. For the - available options, see src/settings.js - Note that for options that are lists, you - need quotation marks in most shells, for - example + -O0 No optimizations (default). This is the recommended + setting for starting to port a project, as it + includes various assertions. + + -O1 Simple optimizations, including asm.js, LLVM -O1 + optimizations, relooping, and no runtime assertions + or C++ exception catching (to re-enable + C++ exception catching, use + -s DISABLE_EXCEPTION_CATCHING=0 ), and enables - -s RUNTIME_LINKED_LIBS="['liblib.so']" - - or - - -s "RUNTIME_LINKED_LIBS=['liblib.so']" - - (without the external "s in either of those, - you would get an error) - - You can also specify a file from which the - value would be read, for example, - - -s DEAD_FUNCTIONS=@/path/to/file - - The contents of /path/to/file will be read, - JSON.parsed and set into DEAD_FUNCTIONS (so - the file could contain - - ["_func1", "func2"] - - ). Note that the path must be absolute, not - relative. - - -g Use debug info. When compiling to bitcode, - this is the same as in clang and gcc, it - adds debug info to the object files. When - compiling from source to JS or bitcode to JS, - it is equivalent to -g3 (keep code as debuggable - as possible, except for discarding LLVM - debug info, so no C/C++ line numbers; use - -g4 to get line number debugging info in JS). - - -g<level> When compiling from bitcode to JS, we can - keep the code debuggable to different - degrees. Each of these levels builds on the - previous: - - 0: Make no effort to keep code debuggable. - Will discard LLVM debug info. (default - in -O1+) - - 1: Preserve (do not minify) whitespace - 2: Preserve function names - 3: Preserve variable names - - 4: Preserve LLVM debug info (if -g was - used when compiling the C/C++ sources), - show line number debug comments, and - generate source maps. This is the highest - level of debuggability. Note that this - may make -O1 and above significantly - slower because JS optimization will be - limited to 1 core. (default in -O0) - - --typed-arrays <mode> 0: No typed arrays - 1: Parallel typed arrays - 2: Shared (C-like) typed arrays (default) - - --js-opts 0: Prevent JS optimizer from running - 1: Use JS optimizer (default) - - --llvm-opts <level> 0: No LLVM optimizations (default in -O0) - 1: -O1 LLVM optimizations (default in -O1) - 2: -O2 LLVM optimizations - 3: -O3 LLVM optimizations (default in -O2+) - - You can also specify arbitrary LLVM options, e.g. - - --llvm-opts "['-O3', '-somethingelse']" - - --llvm-lto <level> 0: No LLVM LTO (default) - 1: LLVM LTO is performed - - 2: We combine all the bitcode and run LLVM opt -O3 - on that (which optimizes across modules, but is - not the same as normal LTO), but do not do normal - LTO - - 3: We do both 2 and then 1 - Note: If LLVM optimizations are not run - (see --llvm-opts), setting this has no - effect. - - Note that LLVM LTO is not perfectly stable yet, - and can can cause code to behave incorrectly. - - --closure <on> 0: No closure compiler (default in -O2 and below) - - 1: Run closure compiler. This greatly reduces - code size and may in some cases increase - runtime speed (although the opposite can also - occur). Note that it takes time to run, and - may require some changes to the code. - - In asm.js mode, closure will only be used on the - 'shell' code around the compiled code (the - compiled code will be processed by the custom - asm.js minifier). - - Note: If closure compiler hits an out-of-memory, - try adjusting JAVA_HEAP_SIZE in the environment - (for example, to 4096m for 4GB). - - Note: Closure is only run if js opts are being - done (-O2 or above, or --js-opts 1). - - --pre-js <file> A file whose contents are added before the - generated code. This is done *before* - optimization, so it will be minified - properly if closure compiler is run. - - --post-js <file> A file whose contents are added after the - generated code This is done *before* - optimization, so it will be minified - properly if closure compiler is run. - - --embed-file <file> A file to embed inside the generated - JavaScript. The compiled code will be able - to access the file in the current directory - with the same name as given here. So if - you do --embed-file dir/file.dat, then - (1) dir/file.dat must exist relative to - where you run emcc, and (2) your compiled - code will be able to find the file by - reading that same path, dir/file.dat. - If a directory is passed here, its entire - contents will be embedded. - - Note: Embedding files is much less - efficient than preloading them. You - should only use it for small amounts - of small files. Instead, use - --preload-file which emits efficient - binary data. - - --preload-file <name> A file to preload before running the - compiled code asynchronously. Otherwise - similar to --embed-file, except that this - option is only relevant when generating - HTML (it uses asynchronous binary XHRs), - or JS that will be used in a web page. - If a directory is passed here, its entire - contents will be preloaded. - Preloaded files are stored in filename.data, - where filename.html is the main file you - are compiling to. To run your code, you - will need both the .html and the .data. - - emcc runs tools/file_packager.py to do the - actual packaging of embedded and preloaded - files. You can run the file packager yourself - if you want, see docs inside that file. You - should then put the output of the file packager - in an emcc --pre-js, so that it executes before - your main compiled code (or run it before in - some other way). - - For more docs on the options --preload-file - accepts, see https://github.com/kripken/emscripten/wiki/Filesystem-Guide - - --exclude-file <name> Files and directories to be excluded from - --embed-file and --preload-file - wildcard is supported - - --shell-file <path> The path name to a skeleton HTML file used - when generating HTML output. The shell file - used needs to have this token inside it: - - {{{ SCRIPT }}} - - (see src/shell.html and - src/shell_minimal.html for examples) - - Note that this argument is ignored if a - target other than HTML is specified using - the -o option. - - --compression <codec> **THIS OPTION IS DEPRECATED** - - Compress both the compiled code and embedded/ - preloaded files. <codec> should be a triple, - - <native_encoder>,<js_decoder>,<js_name> - - where native_encoder is a native executable - that compresses stdin to stdout (the simplest - possible interface), js_decoder is a - JavaScript file that implements a decoder, - and js_name is the name of the function to - call in the decoder file (which should - receive an array/typed array and return - an array/typed array. - Compression only works when generating HTML. - When compression is on, all filed specified - to be preloaded are compressed in one big - archive, which is given the same name as the - output HTML but with suffix .data.compress - - --minify 0 Identical to -g1 - - --js-transform <cmd> <cmd> will be called on the generated code - before it is optimized. This lets you modify - the JavaScript, for example adding some code - or removing some code, in a way that those - modifications will be optimized together with - the generated code properly. <cmd> will be - called with the filename of the generated - code as a parameter; to modify the code, you - can read the original data and then append to - it or overwrite it with the modified data. - <cmd> is interpreted as a space-separated - list of arguments, for example, <cmd> of - "python processor.py" will cause a python - script to be run. - - --split <size> Splits the resulting javascript file into pieces - to ease debugging. This option only works if - Javascript is generated (target -o <name>.js). - Files with function declarations must be loaded - before main file upon execution. - - Without "-g" option: - Creates files with function declarations up - to the given size with the suffix - "_functions.partxxx.js" and a main file with - the suffix ".js". - - With "-g" option: - Recreates the directory structure of the C - source files and stores function declarations - in their respective C files with the suffix - ".js". If such a file exceeds the given size, - files with the suffix ".partxxx.js" are created. - The main file resides in the base directory and - has the suffix ".js". - - Note: this option is deprecated (modern JS debuggers - should work ok even on large files) - - --bind Compiles the source code using the "embind" - bindings approach, which connects C/C++ and JS. - - --ignore-dynamic-linking - - Normally emcc will treat dynamic linking like - static linking, by linking in the code from - the dynamic library. This fails if the same - dynamic library is linked more than once. - With this option, dynamic linking is ignored, - which allows the build system to proceed without - errors. However, you will need to manually - link to the shared libraries later on yourself. - - --js-library <lib> A JavaScript library to use in addition to - those in Emscripten's src/library_* - - -v Turns on verbose output. This will pass - -v to Clang, and also enable EMCC_DEBUG - to details emcc's operations - - --jcache Use a JavaScript cache. This is disabled by - default. When enabled, emcc will store the - results of compilation in a cache and check - the cache when compiling later, something - like what ccache does. This allows incremental - builds - where you are compiling a large - program but only modified a small part of it - - to be much faster (at the cost of more disk - IO for cache accesses). Note that you need - to enable --jcache for both loading and saving - of data, so you must enable it on a full build - for a later incremental build (where you also - enable it) to be sped up. - - Caching works separately on 4 parts of compilation: - 'pre' which is types and global variables; that - information is then fed into 'funcs' which are - the functions (which we parallelize), and then - 'post' which adds final information based on - the functions (e.g., do we need long64 support - code). Finally, 'jsfuncs' are JavaScript-level - optimizations. Each of the 4 parts can be cached - separately, but note that they can affect each - other: If you recompile a single C++ file that - changes a global variable - e.g., adds, removes - or modifies a global variable, say by adding - a printf or by adding a compile-time timestamp, - then 'pre' cannot be loaded from the cache. And - since 'pre's output is sent to 'funcs' and 'post', - they will get invalidated as well, and only - 'jsfuncs' will be cached. So avoid modifying - globals to let caching work fully. - - To work around the problem mentioned in the - previous paragraph, you can use - - emscripten_jcache_printf - - when adding debug printfs to your code. That - function is specially preprocessed so that it - does not create a constant string global for - its first argument. See emscripten.h for more - details. Note in particular that you need to - already have a call to that function in your - code *before* you add one and do an incremental - build, so that adding an external reference - (also a global property) does not invalidate - everything. - - Note that you should use -g during the linking - stage (bitcode to JS), for jcache to work - (otherwise, JS minification can confuse it). - - --clear-cache Manually clears the cache of compiled - emscripten system libraries (libc++, - libc++abi, libc). This is normally - handled automatically, but if you update - llvm in-place (instead of having a different - directory for a new version), the caching - mechanism can get confused. Clearing the - cache can fix weird problems related to - cache incompatibilities, like clang failing - to link with library files. This also clears - other cached data like the jcache and - the bootstrapped relooper. After the cache - is cleared, this process will exit. - - --save-bc PATH When compiling to JavaScript or HTML, this - option will save a copy of the bitcode to - the specified path. The bitcode will include - all files being linked, including standard - libraries, and after any link-time optimizations - (if any). - - --memory-init-file <on> - - 0: Do not emit a separate memory initialization - file, keep the static initialization inside - the generated JavaScript as text (default) - - 1: Emit a separate memory initialization file - in binary format. This is more efficient than - storing it as text inside JavaScript, but does - mean you have another file to publish. - - -Wno-warn-absolute-paths - - If not specified, the compiler will warn about any - uses of absolute paths in -I and -L command line - directives. Pass this flag on the command line - to hide these warnings and acknowledge that the - explicit use of absolute paths is intentional. - - --proxy-to-worker Generates both html and js files. The main - program is in js, and the html proxies to/from it. - - --emrun Enables the generated output to be aware of the - emrun command line tool. This allows stdout, stderr - and exit(returncode) capture when running the - generated application through emrun. - - --em-config Specifies the location of the .emscripten configuration - file for the current compiler run. If not specified, - the environment variable EM_CONFIG is read for this - file, and if that is not set, the default location - ~/.emscripten is assumed. - - --default-obj-ext .ext - - Specifies the file suffix to generate if the location - of a directory name is passed to -o directive, e.g. - - emcc -c a.c -o dir/ - - will by default generate an output name 'dir/a.o', - but this cmdline param can be passed to generate a - file with a custom suffix 'dir/a.ext'. + -s ALIASING_FUNCTION_POINTERS=1 + + This is the recommended setting when you want a + reasonably optimized build that is generated as + quickly as possible (it builds much faster than -O2). + + (Note: for details on the affects of different + opt levels, see apply_opt_level() in + tools/shared.py and also src/settings.js.) + + -O2 As -O1, plus various js-level optimizations and + LLVM -O3 optimizations. This is the recommended + setting for a release build: slower compilation + time in return for the smallest and fastest + output. + + -O3 As -O2, plus additional optimizations that can + take a significant amount of compilation time and/or + are relatively new. + + For tips on optimizing your code, see + https://github.com/kripken/emscripten/wiki/Optimizing-Code + + -s OPTION=VALUE JavaScript code generation option passed + into the emscripten compiler. For the + available options, see src/settings.js + Note that for options that are lists, you + need quotation marks in most shells, for + example + + -s RUNTIME_LINKED_LIBS="['liblib.so']" + + or + + -s "RUNTIME_LINKED_LIBS=['liblib.so']" + + (without the external "s in either of those, + you would get an error) + + You can also specify a file from which the + value would be read, for example, + + -s DEAD_FUNCTIONS=@/path/to/file + + The contents of /path/to/file will be read, + JSON.parsed and set into DEAD_FUNCTIONS (so + the file could contain + + ["_func1", "func2"] + + ). Note that the path must be absolute, not + relative. + + -g Use debug info. When compiling to bitcode, + this is the same as in clang and gcc, it + adds debug info to the object files. When + compiling from source to JS or bitcode to JS, + it is equivalent to -g3 (keep code as debuggable + as possible, except for discarding LLVM + debug info, so no C/C++ line numbers; use + -g4 to get line number debugging info in JS). + + -g<level> When compiling from bitcode to JS, we can + keep the code debuggable to different + degrees. Each of these levels builds on the + previous: + + -g0 Make no effort to keep code debuggable. + Will discard LLVM debug info. (default + in -O1+) + -g1 Preserve (do not minify) whitespace + -g2 Preserve function names + -g3 Preserve variable names + -g4 Preserve LLVM debug info (if -g was + used when compiling the C/C++ sources), + show line number debug comments, and + generate source maps. This is the highest + level of debuggability. Note that this + may make -O1 and above significantly + slower because JS optimization will be + limited to 1 core. (default in -O0) + + --typed-arrays <mode> 0: No typed arrays + 1: Parallel typed arrays + 2: Shared (C-like) typed arrays (default) + + --js-opts 0: Prevent JS optimizer from running + 1: Use JS optimizer (default) + + --llvm-opts <level> 0: No LLVM optimizations (default in -O0) + 1: -O1 LLVM optimizations (default in -O1) + 2: -O2 LLVM optimizations + 3: -O3 LLVM optimizations (default in -O2+) + + You can also specify arbitrary LLVM options, e.g. + + --llvm-opts "['-O3', '-somethingelse']" + + --llvm-lto <level> 0: No LLVM LTO (default) + 1: LLVM LTO is performed + 2: We combine all the bitcode and run LLVM opt -O3 + on that (which optimizes across modules, but is + not the same as normal LTO), but do not do normal + LTO + 3: We do both 2 and then 1 + Note: If LLVM optimizations are not run + (see --llvm-opts), setting this has no + effect. + + Note that LLVM LTO is not perfectly stable yet, + and can can cause code to behave incorrectly. + + --closure <on> 0: No closure compiler (default in -O2 and below) + 1: Run closure compiler. This greatly reduces + code size and may in some cases increase + runtime speed (although the opposite can also + occur). Note that it takes time to run, and + may require some changes to the code. + + In asm.js mode, closure will only be used on the + 'shell' code around the compiled code (the + compiled code will be processed by the custom + asm.js minifier). + + Note: If closure compiler hits an out-of-memory, + try adjusting JAVA_HEAP_SIZE in the environment + (for example, to 4096m for 4GB). + + Note: Closure is only run if js opts are being + done (-O2 or above, or --js-opts 1). + + --pre-js <file> A file whose contents are added before the + generated code. This is done *before* + optimization, so it will be minified + properly if closure compiler is run. + + --post-js <file> A file whose contents are added after the + generated code This is done *before* + optimization, so it will be minified + properly if closure compiler is run. + + --embed-file <file> A file to embed inside the generated + JavaScript. The compiled code will be able + to access the file in the current directory + with the same name as given here. So if + you do --embed-file dir/file.dat, then + (1) dir/file.dat must exist relative to + where you run emcc, and (2) your compiled + code will be able to find the file by + reading that same path, dir/file.dat. + If a directory is passed here, its entire + contents will be embedded. + + Note: Embedding files is much less + efficient than preloading them. You + should only use it for small amounts + of small files. Instead, use + --preload-file which emits efficient + binary data. + + --preload-file <name> A file to preload before running the + compiled code asynchronously. Otherwise + similar to --embed-file, except that this + option is only relevant when generating + HTML (it uses asynchronous binary XHRs), + or JS that will be used in a web page. + If a directory is passed here, its entire + contents will be preloaded. + Preloaded files are stored in filename.data, + where filename.html is the main file you + are compiling to. To run your code, you + will need both the .html and the .data. + + emcc runs tools/file_packager.py to do the + actual packaging of embedded and preloaded + files. You can run the file packager yourself + if you want, see docs inside that file. You + should then put the output of the file packager + in an emcc --pre-js, so that it executes before + your main compiled code (or run it before in + some other way). + + For more docs on the options --preload-file + accepts, see https://github.com/kripken/emscripten/wiki/Filesystem-Guide + + --exclude-file <name> Files and directories to be excluded from + --embed-file and --preload-file + wildcard is supported + + --shell-file <path> The path name to a skeleton HTML file used + when generating HTML output. The shell file + used needs to have this token inside it: + {{{ SCRIPT }}} + (see src/shell.html and + src/shell_minimal.html for examples) + Note that this argument is ignored if a + target other than HTML is specified using + the -o option. + + --compression <codec> **THIS OPTION IS DEPRECATED** + + Compress both the compiled code and embedded/ + preloaded files. <codec> should be a triple, + + <native_encoder>,<js_decoder>,<js_name> + + where native_encoder is a native executable + that compresses stdin to stdout (the simplest + possible interface), js_decoder is a + JavaScript file that implements a decoder, + and js_name is the name of the function to + call in the decoder file (which should + receive an array/typed array and return + an array/typed array. + Compression only works when generating HTML. + When compression is on, all filed specified + to be preloaded are compressed in one big + archive, which is given the same name as the + output HTML but with suffix .data.compress + + --minify 0 Identical to -g1 + + --js-transform <cmd> <cmd> will be called on the generated code + before it is optimized. This lets you modify + the JavaScript, for example adding some code + or removing some code, in a way that those + modifications will be optimized together with + the generated code properly. <cmd> will be + called with the filename of the generated + code as a parameter; to modify the code, you + can read the original data and then append to + it or overwrite it with the modified data. + <cmd> is interpreted as a space-separated + list of arguments, for example, <cmd> of + "python processor.py" will cause a python + script to be run. + + --split <size> Splits the resulting javascript file into pieces + to ease debugging. This option only works if + Javascript is generated (target -o <name>.js). + Files with function declarations must be loaded + before main file upon execution. + + Without "-g" option: + Creates files with function declarations up + to the given size with the suffix + "_functions.partxxx.js" and a main file with + the suffix ".js". + + With "-g" option: + Recreates the directory structure of the C + source files and stores function declarations + in their respective C files with the suffix + ".js". If such a file exceeds the given size, + files with the suffix ".partxxx.js" are created. + The main file resides in the base directory and + has the suffix ".js". + + Note: this option is deprecated (modern JS debuggers + should work ok even on large files) + + --bind Compiles the source code using the "embind" + bindings approach, which connects C/C++ and JS. + + --ignore-dynamic-linking Normally emcc will treat dynamic linking like + static linking, by linking in the code from + the dynamic library. This fails if the same + dynamic library is linked more than once. + With this option, dynamic linking is ignored, + which allows the build system to proceed without + errors. However, you will need to manually + link to the shared libraries later on yourself. + + --js-library <lib> A JavaScript library to use in addition to + those in Emscripten's src/library_* + + -v Turns on verbose output. This will pass + -v to Clang, and also enable EMCC_DEBUG + to details emcc's operations + + --jcache Use a JavaScript cache. This is disabled by + default. When enabled, emcc will store the + results of compilation in a cache and check + the cache when compiling later, something + like what ccache does. This allows incremental + builds - where you are compiling a large + program but only modified a small part of it - + to be much faster (at the cost of more disk + IO for cache accesses). Note that you need + to enable --jcache for both loading and saving + of data, so you must enable it on a full build + for a later incremental build (where you also + enable it) to be sped up. + + Caching works separately on 4 parts of compilation: + 'pre' which is types and global variables; that + information is then fed into 'funcs' which are + the functions (which we parallelize), and then + 'post' which adds final information based on + the functions (e.g., do we need long64 support + |