Re: Removal of EMSCRIPTEN_ROOT from config file

['Sam Clegg' via emscripten-discuss]

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  wrote:
>
> On Tue, Oct 30, 2018 at 2:16 AM Jukka Jylänki  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 

Re: Removal of EMSCRIPTEN_ROOT from config file

['Sam Clegg' via emscripten-discuss]

On Tue, Oct 30, 2018 at 2:16 AM Jukka Jylänki  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 
> 

Re: Removal of EMSCRIPTEN_ROOT from config file

[Jukka Jylänki]

> 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.

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.
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.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Leon Krause]

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.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Floh]

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 > 
> 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  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. 
> >> >> 
> >> >> 

Re: Removal of EMSCRIPTEN_ROOT from config file

[Sam Clegg]

On Thu, Oct 18, 2018 at 11:51 AM Floh  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  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 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 

Re: Removal of EMSCRIPTEN_ROOT from config file

[Floh]

> 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.

Cheers!
-Floh.

On Wednesday, 17 October 2018 14:41:05 UTC+2, Sam Clegg wrote:
>
> On Wed, Oct 10, 2018 at 1:56 PM Floh > 
> 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 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.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Sam Clegg]

On Wed, Oct 10, 2018 at 1:56 PM Floh  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 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.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Beuc]

This makes sense, if we can configure EMSCRIPTEN_ROOT automagically, all
the better.
I mentioned LLVM_ROOT since Sam's use case was "parses the config file
and finds EMSCRIPTEN_ROOT pointing to different version" - I mean if
.emscripten is out-of-sync there will be other problems, but that's when
we'd have to use EM_CONFIG anyway.

- Sylvain

On 12/10/2018 00:37, Alon Zakai wrote:
> LLVM_ROOT is somewhat different - we have to be given the path to LLVM
> somehow. But emscripten code should know where emscripten is (since
> every python script can tell, etc.). So there is a risk of getting out
> of sync for EMSCRIPTEN_ROOT, and I think it makes sense to remove it,
> but not LLVM_ROOT, unless I'm missing something.
>
> On Wed, Oct 10, 2018 at 3:00 AM Beuc  > wrote:
>
> Hi,
>
> I believe we'd need to deal with LLVM_ROOT as well, since the fastcomp
> version needs to be in sync with emscripten's?
>
> - Sylvain
>
> On 10/10/2018 02:41, 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.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Alon Zakai]

LLVM_ROOT is somewhat different - we have to be given the path to LLVM
somehow. But emscripten code should know where emscripten is (since every
python script can tell, etc.). So there is a risk of getting out of sync
for EMSCRIPTEN_ROOT, and I think it makes sense to remove it, but not
LLVM_ROOT, unless I'm missing something.

On Wed, Oct 10, 2018 at 3:00 AM Beuc  wrote:

> Hi,
>
> I believe we'd need to deal with LLVM_ROOT as well, since the fastcomp
> version needs to be in sync with emscripten's?
>
> - Sylvain
>
> On 10/10/2018 02:41, 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.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Floh]

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.

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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removal of EMSCRIPTEN_ROOT from config file

[Beuc]

Hi,

I believe we'd need to deal with LLVM_ROOT as well, since the fastcomp
version needs to be in sync with emscripten's?

- Sylvain

On 10/10/2018 02:41, 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.

Removal of EMSCRIPTEN_ROOT from config file

[Sam Clegg]

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.