emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler
Other
25.91k stars 3.32k forks source link

FR: allow overriding specific entries from EMCC_CONFIG on commandline #8668

Closed steven-johnson closed 4 years ago

steven-johnson commented 5 years ago

If you need to build against (say) different LLVM versions for different builds, editing your .emscripten file is inconvenient; you can override the entire file via the EM_CONFIG env var (or the --em-config flag), but these require that you specify the entire file contents. It would be very handy to be able to override just some of the file via a flag.

I currently work around this in my Makefile by rules like

MY_LLVM_ROOT = /path/to/my/llvm
EMCC_CONFIG = $(shell cat $(HOME)/.emscripten | grep -v LLVM_ROOT | tr '\n' ';')LLVM_ROOT='$(MY_LLVM_ROOT)'

...which isn't awful, but seems more complex than necessary.

sbc100 commented 5 years ago

By default emscripten creates a config file that looks in the environment for LLVM doesn't it?

e.g.

LLVM_ROOT = os.path.expanduser(os.getenv('LLVM', '/usr/local/google/home/sbc/dev/wasm/emscripten-fastcomp/build/bin')) 

So simply setting LLVM=... should do the trick for you.

I use this feature every day... but I have to say I'm not big fan of using the environment to do configuration in general.

steven-johnson commented 5 years ago

Yes, it does, but the problem is that I have a need to support multiple LLVM_ROOT values on the same build machine (varying by build targets); I don't think that EMCC will rewrite the .emscripten config file later (if I just change the env var).

(I really dislike relying on env vars this way and consider it an antipattern in most cases, but various projects I'm working with use them extensively)

sbc100 commented 5 years ago

What I meant is that the deafault .emscripten file includes a call to os.getenv('LLVM').. so it will dynamically change according to you LLVM env var already .. no need to re-write the file.

steven-johnson commented 5 years ago

That's not what mine looks like; my default .emscripten (on OSX) looks like

import os
LLVM_ROOT = '/Users/srj/GitHub/emsdk/clang/e1.38.31_64bit'
EMSCRIPTEN_NATIVE_OPTIMIZER = '/Users/srj/GitHub/emsdk/clang/e1.38.31_64bit/optimizer'
BINARYEN_ROOT = '/Users/srj/GitHub/emsdk/clang/e1.38.31_64bit/binaryen'
NODE_JS = '/Users/srj/GitHub/emsdk/node/8.9.1_64bit/bin/node'
EMSCRIPTEN_ROOT = '/Users/srj/GitHub/emsdk/emscripten/1.38.31'
SPIDERMONKEY_ENGINE = ''
V8_ENGINE = ''
TEMP_DIR = '/var/folders/p4/b4qsbqqx47vc4g64gwzxw82m004j3k/T'
COMPILER_ENGINE = NODE_JS
JS_ENGINES = [NODE_JS]
sbc100 commented 5 years ago

Thats a .emscripten file produced by emsdk. Try removing it completely and then emscripten will generate one automatically for you that has a lot of boilerplate, include the os.getenv() line which is what you want.

If you users are emsdk users perhaps you can have one-time script the converts their config file to use os.getenv and from then on it will be dynamic?

sbc100 commented 5 years ago

FWIW I think this state seems reasonable. emscripten is by default configurable. emsdk (which packages specific versions) is locked to specific versions.

If the above approach doesn't work we can consider modifying emsdk to generate a config file more like emscriptens (in which case the emsdk repo is a better place for this bug).

steven-johnson commented 5 years ago

OK, I guess I'm confused: I thought that emsdk was the recommended way for most users to install Emscripten. Is that not the case?

sbc100 commented 5 years ago

It is, yes. Its the recommended way to get a complete pre-packaged version of emscripten bundled with a fixed set of known-good dependencies.

steven-johnson commented 5 years ago

Ah, ok, I didn't realize that emsdk had a separate set of tracking issues.

Anyway: I have a workaround which works (but just feels clunky).

kripken commented 5 years ago

We could make the emsdk emit code that uses those env vars too. I'm not sure if that's better or not, though.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

sbc100 commented 4 years ago

All values in the emscripten config file can not be overridden by the environment via EM_<name> .. hopefully that addresses this issue?