Everything still working, so no worries :)
BUT: maybe interesting info for you, I tried removing the --em-config
argument somewhat expecting that everything still works, but got compile
errors like this:
opt: Unknown command line argument '-lower-non-em-intrinsics'. Try:
'/Users/floh/projects/emsdk/clang/fastcomp/build_incoming_64/bin/opt -help'
opt: Did you mean '-lower-guard-intrinsic'?
ERROR:root:Failed to run llvm optimizations:
I guess it doesn't find the .emscripten file without the --em-config (which
may be in a non-standard location in my case, it's in the toplevel
"emsdk-portable" directory where my "workspace SDK" is installed), and
probably calls some system LLVM tools instead of from the fastcomp location.
One thing is a bit strange though, as I wrote before, I don't have the
EM_CONFIG env variable set anywhere. But the .emscripten file is a python
script and runs this:
emsdk_path=os.path.dirname(os.environ.get('EM_CONFIG')).replace('\\', '/')
But without an EM_CONFIG this should fail hard, because os.path.dirname()
is called with None... so the only way this would work is if the
--em-config emcc arg sets the EM_CONFIG environment variable from within
python (and after rummaging around in "tools/shared.py" this is indeed the
case, so riddle solved).
So all good :)
-Floh.
On Tuesday, 23 October 2018 11:51:07 UTC+2, Sam Clegg wrote:
>
> On Thu, Oct 18, 2018 at 11:51 AM Floh <[email protected] <javascript:>>
> wrote:
> >
> > > However, i don't think you can change the emscripten SDK dir by using
> --em-config (can you?).
> >
> > It does seem to work when using both --em-config and --cache both for
> emcc and emar. This is what I'm doing to use a "local" workspace emscripten
> install for cmake (all emscripten tools will also be called with their full
> path, not relying on the global PATH):
> >
> >
> https://github.com/floooh/fips/blob/055b454fa0f55468d3342d6ffbba6e798267ce59/cmake-toolchains/emscripten.toolchain.cmake#L162-L180
>
> >
> > I'm doing this for a long time now, but IFIR just calling the emscripten
> tools with a full path wasn't enough to separate different SDKs from each
> other.
> >
> > It definitely works to keep this 'workspace' emscripten separate from a
> globally installed emscripten SDK (which is used when simply calling "emcc"
> from the command line). I haven't tested for a while to have separate
> workspaces with separate emscripten SDK versions though.
>
> IIUC my change should effect your setup, but perhaps I'm
> misunderstanding. I've not changed the way `--em-config` or
> `--cache` work. IIUC emscripten has never had a way to change the
> emscripten directory once one of the tools is run. e.g. if you run
> `/full/path/to/emcc` the emscripten used will always be
> `/full/path/to`, the config cannot effect that directory. My
> intention with this change is to make this even more explicit.
>
> Another way of putting it: Previously you could run
> `/path/to/version_one/emcc` with an emconfig file that contained
> `EMSCRIPTEN_ROOT=/path/to/version_two` but in this case
> `/path/to/version_two` would never actually be used.
>
> Could you test your setup with HEAD and let me know if I broke
> anything for you?
>
> > -Floh.
> >
> > On Wednesday, 17 October 2018 14:41:05 UTC+2, Sam Clegg wrote:
> >>
> >> On Wed, Oct 10, 2018 at 1:56 PM Floh <[email protected]> wrote:
> >> >
> >> > Does this fix change the behaviour of the the "--em-config" and
> "--cache" cmdline args of emcc and emar to point to a local emscripten SDK
> install?
> >> >
> >> > For me it's important that I don't have that "one and only" central
> emscripten SDK, but separate versions per "workspace", and I'm using the
> "--em-config" and "--cache" to isolate those different SDKs (I'm not
> setting any environment variables like EM_CONFIG or EMSCRIPTEN_ROOT either
> btw).
> >> >
> >> > As long as the cmdline args continue working, I guess I'm fine with
> the change.
> >> >
> >>
> >> I don't think this change will effect those command line flags.
> >>
> >> However, i don't think you can change the emscripten SDK dir by using
> >> --em-config (can you?). If you run emcc or emar the emscripten SDK
> >> you get is based on where those commands are found (i.e. `which
> >> emcc`). This change is ephasising that fact. The em-config can
> >> control other things such as the LLVM location and the binaryen
> >> location, but my understanding is that its argv0 that is used to find
> >> emscripten. If you want t to switch your emscripten directory you
> >> would need to update your PATH or use a fully qualified path to emcc.
> >>
> >>
> >> > Cheers!
> >> > -Floh.
> >> >
> >> > On Wednesday, 10 October 2018 02:41:26 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 [email protected]
> <javascript:>.
> >> > 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 [email protected] <javascript:>.
>
> > 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
