Issue 5020 - [emscripten] Part 4: Make compile script Windows-compatible

compile

 #!/usr/bin/env python
 
 import argparse
 import os
 import subprocess
 import sys
 
 BASE_DIR = os.path.dirname(__file__)
 SOURCE_DIR = os.path.join(BASE_DIR, 'compiled')
 SOURCE_FILES = [
@@ skipping 18 matching lines @@
     'NO_FILESYSTEM': 1,
     'INVOKE_RUN': 0,
     'TEXTDECODER': 0,
     'EXPORTED_RUNTIME_METHODS': ['cwrap', 'ccall', 'stringToAscii'],
 }
 DEFINES = []
 ADDITIONAL_PARAMS = ['-O3', '-m32', '-std=gnu++14', '--memory-init-file', '0',
                      '--emit-symbol-map']
 
 
 def getenv(emscripten_config):

[Vasily Kuznetsov, 2017/03/23 19:26:53]

Instead of running `emsdk_env.sh` located at `emscripten_path` we now use load
emscripten config (which is in python) and read configuration variables from
there.

     scope = {}
     execfile(emscripten_config, scope, scope)
     env = os.environ.copy()
     env.update({
         'EM_CONFIG': emscripten_config,

[Wladimir Palant, 2017/03/23 14:10:57]

It seems that Emscripten itself only needs this environment variable, everything
else will be read from the config file.

         'EMSCRIPTEN': scope['EMSCRIPTEN_ROOT'],
         'PYTHON': scope.get('PYTHON', sys.executable),
         'NODE_JS': scope.get('NODE_JS', 'node'),

[Wladimir Palant, 2017/03/23 14:10:57]

This will typically be misconfigured on Windows, see
https://github.com/juj/emsdk/commit/87cb951ec7b9b3388c16c22aa259807a1c901c7a
which still didn't make it into any emsdk releases.

     })
     return env
 
 
 def generate_bindings(env):
     params = [
         env['PYTHON'], os.path.join(env['EMSCRIPTEN'], 'emcc'), BINDINGS_FILE,

[Vasily Kuznetsov, 2017/03/23 19:26:53]

We use python interpreter configured in emscripten config (or default to our
python) to run `emcc` because on windows we can't just run since shebang line
doesn't work.

[Wladimir Palant, 2017/03/24 06:20:41]

There is emcc.bat on Windows but it relies on Python being in PATH. It's better
to explicitly run the Python version that Emscripten came with - and that
approach doesn't require platform-specific code.

         '-o', BINDINGS_GENERATOR, '-std=gnu++14', '-DPRINT_BINDINGS',
         '-s', 'WARN_ON_UNDEFINED_SYMBOLS=0',
     ]
     subprocess.check_call(params, env=env)
 
     with open(BINDINGS_OUTPUT, 'w') as file:
-        subprocess.check_call([env['NODE_JS'], BINDINGS_GENERATOR], stdout=file)
+        subprocess.check_call([env['NODE_JS'], BINDINGS_GENERATOR],

[Vasily Kuznetsov, 2017/03/23 19:26:53]

We use the path to node from emscripten config (defaulting to just calling
"node" and hoping that it's in the path) instead of previous unix-specific way
of determining the path to node.

[Wladimir Palant, 2017/03/24 06:20:41]

The drawback here is that Emscripten comes with a pretty old Node version. But
then again - that's the Node version they tested with, so there shouldn't be any
issues.

+                              stdout=file)
 
 
 def run_compiler(env, debug=False, tracing=False):
     params = [
         env['PYTHON'], os.path.join(env['EMSCRIPTEN'], 'emcc'),

[Vasily Kuznetsov, 2017/03/23 19:26:53]

Again invoke python script with a python interpreter since it won't work
without.

         '-o', COMPILER_OUTPUT,
         '--post-js', BINDINGS_OUTPUT,
     ]
     params.extend(SOURCE_FILES)
     params.extend('-D' + flag for flag in DEFINES)
     for key, value in GENERATION_PARAMS.iteritems():
         params.extend(['-s', '{}={}'.format(key, str(value))])
     if debug:
         params.append('-g1')
     if tracing:
         params.append('--tracing')
     params.extend(ADDITIONAL_PARAMS)
     subprocess.check_call(params, env=env)
 
 
 if __name__ == '__main__':
     parser = argparse.ArgumentParser(
         description='Compile Emscripten-based C++ code to JavaScript'
     )
     parser.add_argument(
         '--emscripten-config',

[Vasily Kuznetsov, 2017/03/23 19:26:53]

We switch to using emscripten config instead of using the path to emscripten
installation as before. This is not completely obvious to me since we didn't
need the config before and now we need it. As I understood, if we run `emcc` at
least once, the config will be generated, so the only situation where the change
would cause issues is if we have never un emscripten.

[Wladimir Palant, 2017/03/24 06:20:41]

emsdk construct_env (which is what we have been calling essentially) doesn't
produce any ouput on Windows - it cannot set environment variables for the
current shell, so instead it manipulates the environment settings in the
registry. Either way, parsing that output was quite a hack.

I would have preferred loading emsdk as a module but it doesn't have anything
resembling a stable API. So loading the config file seems to be the least hacky
way to do it (yes, it is a Python file - "import os" at the top but then only
defining constants). Emscripten defaults to ~/.emscripten for it on all
platforms but allows overriding via EM_CONFIG environment variable. So we also
allow overriding the config path and will forward it via environment.
Actually, you need emsdk in order to *install* Emscripten (emsdk can manage
multiple Emscripten versions). The path to emcc is written into the config file
then. So if you installed Emscripten you should always have that config file.

         metavar='DIR',
         default=os.path.expanduser('~/.emscripten'),
         help='Emscripten installation directory'
     )
     parser.add_argument(
         '-d', '--debug',
         action='store_true',
         help='Disable code minification'
     )
     parser.add_argument(
         '-t', '--tracing',
         action='store_true',
         help='Enable memory tracing'
     )
     args = parser.parse_args()
 
     env = getenv(args.emscripten_config)
     generate_bindings(env)
     run_compiler(env, debug=args.debug, tracing=args.tracing)