readme: hard tabs, comment shifting

1 files changed, 1743 insertions, 1694 deletions

diff --git a/emcc b/emcc
index 6d8ff6f6..a6b2a630 100755
--- a/emcc
+++ b/emcc
@@ -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,26 +74,29 @@ 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)
@@ -108,440 +111,462 @@ 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
+	-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
 
-                              -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
-                           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 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 compi