Closed steven-johnson closed 4 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.
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)
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.
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]
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?
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).
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?
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.
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).
We could make the emsdk emit code that uses those env vars too. I'm not sure if that's better or not, though.
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.
All values in the emscripten config file can not be overridden by the environment via EM_<name>
.. hopefully that addresses this issue?
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
...which isn't awful, but seems more complex than necessary.