I created a partial revert to keep EMSCRIPTEN_ROOT in the config for now: https://github.com/kripken/emscripten/pull/7411 On Tue, Oct 30, 2018 at 10:09 AM Sam Clegg <s...@google.com> wrote: > > On Tue, Oct 30, 2018 at 2:16 AM Jukka Jylänki <juj...@gmail.com> wrote: > > > > > Imagine you run `emcc` and if > > parses the config file and finds EMSCRIPTEN_ROOT pointing to different > > version of emscripten. > > > > I would recommend not removing EMSCRIPTEN_ROOT, but rather issuing a > > warning if this scenario is met (if we don't already?). It would be a > > good way to validate that the other fields in the .emscripten file are > > likely valid or invalid too. > > This was my first instinct too, and I initially landed that but had to > revert it due to difficulty comparing and normalizing paths on windows > (8.3 path names I think). See > https://github.com/kripken/emscripten/pull/6863. > > > The --em-config cmdline param and EM_CONFIG env. vars are ways to > > point to a custom .emscripten file, that allow locating > > EMSCRIPTEN_ROOT on a per-invocation or per-environment basis. Emsdk > > uses that in its --embedded mode to allow one to have multiple > > separate terminal windows with different Emscripten versions active. > > --em-config and EM_CONFIG continue to work as before. However I think > maybe there is some confusion here about how they work. Setting the > config file does not and cannot change the emscripten directory as far > as I can tell. This is because parsing of the config file done in > `tools/shared.py` and the emscripten root is obviously already > determined before this file is loaded. Maybe i'm wrong or maybe this > was different in the past? > > Part of the motivation for this change to avoid such confusion. > > I'm a big fan of supporting multiple emscripten versions and multiple > config files and I don't think this change makes it harder. My > understanding of the --embedded mode is that it allows the config file > to be located alongside the each different emscripten version. I > don't think this change effects that behaviour does it? > > I think the only use case for EMSCRIPTEN_ROOT in the config file is > for tools such as scons, make (and Godot above) in the case when emcc > is not in the PATH. In that sense this is a config setting not for > emscripten itself but for consumers of emscripten. emscripten itself > should not be reading it. For the other tools we decided that > EMSCRIPTEN_ROOT in the environment was an acceptable solution for > those that don't want to use PATH. I'm not sure if that is acceptable > for Gotot too? It sounds like maybe it won't work for them so I might > have to revert this change after all. > > > > ma 29. lokak. 2018 klo 23.58 Leon Krause (l...@leonkrause.com) kirjoitti: > > > > > > Godot Engine reads EMSCRIPTEN_ROOT from the file specified by EM_CONFIG or > > > ~/.emscripten. Since emcc is not usually available in PATH, if > > > EMSCRIPTEN_ROOT > > > is removed, it will no longer be possible to locate it automatically. The > > > user > > > has to either manually add emcc to PATH, or source the environment > > > initialization script every time before they build. > > > > > > As is, if `emsdk install` and `emsdk activate` have run once, just one > > > command > > > (invoking SCons) is enough to build Godot. Additional steps mean we'll > > > have more > > > users having issues with their builds. > > > > > > Most users building Godot with Emscripten don't know or care about > > > working with > > > multiple Emscripten installations. In that sense, using multiple > > > Emscripten > > > installations is a valid, but rare use case. > > > > > > > > > On Wednesday, October 10, 2018 at 2:41:26 AM UTC+2, Sam Clegg wrote: > > >> > > >> TLDR: There is a field in called EMSCRIPTEN_ROOT in the config file > > >> which in theory can be used by external tools to find the "active" > > >> emscripten. I'm proposing to remove it. > > >> > > >> --- > > >> > > >> Maintaining this field has a cost and it can get out of sync with the > > >> emscripten you are actually using. Imagine you run `emcc` and if > > >> parses the config file and finds EMSCRIPTEN_ROOT pointing to different > > >> version of emscripten. > > >> > > >> The two current users of EMSCRIPTEN_ROOT that I know of are the scons > > >> support: > > >> https://github.com/kripken/emscripten/blob/incoming/tools/scons/site_scons/site_tools/emscripten/emscripten.py > > >> And ammo.js: https://github.com/kripken/ammo.js/blob/master/make.py#L17 > > >> > > >> In both of these cases a better solution would be either: > > >> 1) looks for `emcc` in the $PATH > > >> 2) check for EMSCRIPTEN_ROOT in the environment. > > >> > > >> Parsing the config file is also a rather brittle solution, and > > >> prevents us from iterating on the config file format and how its > > >> parses. It also uses python's `eval` which is nasty. > > >> > > >> Any objections to following this path? > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "emscripten-discuss" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to emscripten-discuss+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "emscripten-discuss" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to emscripten-discuss+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout.
-- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
