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

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

Reply via email to