I'm not on Discord, just mention me in the ticket (floooh) and I'll be
there ;)
On Wednesday, 14 April 2021 at 18:45:57 UTC+2 s...@google.com wrote:
> On Wed, Apr 14, 2021 at 2:44 AM Floh wrote:
>
>> > Is there some reason you don't want to add the emscripten directory to
>> you PATH? Is that
On Wed, Apr 14, 2021 at 2:44 AM Floh wrote:
> > Is there some reason you don't want to add the emscripten directory to
> you PATH? Is that somehow worse than setting EM_CONFIG and then parsing it?
>
> Because there isn't a single "emscripten directory", but one emscripten
> directory per "worksp
> Is there some reason you don't want to add the emscripten directory to
you PATH? Is that somehow worse than setting EM_CONFIG and then parsing it?
Because there isn't a single "emscripten directory", but one emscripten
directory per "workspace directory". I might cd to a different workspace
On Tue, Apr 13, 2021 at 1:27 PM Floh wrote:
> Yeah, I never used python literals in EM_CONFIG, misunderstanding on my
> part :)
>
> About the other thing:
>
> > a) Use `which emcc` to find where emscripten is
>
> In my case, emcc is not in the path because this is a local installation
> (via "ems
Small PS to my last post:
In my 'cmake wrapper' (which also takes care of managing a lokal
"per-workspace" emscripten SDK installation) I have added the following
subcommands on top of emsdk (other command simply wrap existing emsdk
subcommands)
# show path of the local .emscripten file:
> fip
Yeah, I never used python literals in EM_CONFIG, misunderstanding on my
part :)
About the other thing:
> a) Use `which emcc` to find where emscripten is
In my case, emcc is not in the path because this is a local installation
(via "emsdk activate --embedded") without any traces in the environm
On Tue, Apr 13, 2021 at 3:46 AM Floh wrote:
> I guess this was released in 2.0.17 yesterday (according to the release
> notes at least)? Happy to report that nothing broke on my side ;)
>
> (I'm extracting the EMSCRIPTEN_ROOT value for use in a cmake toolchain
> file by evaluating the .emscripten
I guess this was released in 2.0.17 yesterday (according to the release
notes at least)? Happy to report that nothing broke on my side ;)
(I'm extracting the EMSCRIPTEN_ROOT value for use in a cmake toolchain file
by evaluating the .emscripten config file, and this still seems to work,
I'm stil
FYI, I'm hoping to remove this feature this week:
https://github.com/emscripten-core/emscripten/pull/13855
IIUC nobody is relying on it anymore.
On Mon, Jul 20, 2020 at 8:57 AM Sam Clegg wrote:
>
>
> On Thu, May 21, 2020 at 11:10 AM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss
On Thu, May 21, 2020 at 11:10 AM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> It will be next week at the earliest -- I am currently elbow-deep in work
> on the Halide build/test setup (and, as it turns out, the emcc testing
> hasn't been enabled for our
On Thu, May 21, 2020 at 12:46 PM Floh wrote:
>
> > If you mean literally multiple emsdk checkouts, then yes, with
> --embedded allows them to work at the same time with neither one being the
> default.
>
> This is the important use case for me, not the other one. I have a setup
> helper script wh
> If you mean literally multiple emsdk checkouts, then yes, with --embedded
allows them to work at the same time with neither one being the default.
This is the important use case for me, not the other one. I have a setup
helper script which installs a "local" emsdk in a subdirectory with
--em
On Thu, May 21, 2020 at 9:41 AM Floh wrote:
> > I really want to stop people from trying to do this. I'd much rather
> the PATH was way one finds emscripten. e.g. `which emcc`. Failing that
> an environment variable.
>
> What about having several emsdk installations side by side though, wit
It will be next week at the earliest -- I am currently elbow-deep in work
on the Halide build/test setup (and, as it turns out, the emcc testing
hasn't been enabled for our public repo recently, so it might have broken
for other reasons).
On Thu, May 21, 2020 at 8:59 AM 'Sam Clegg' via emscripten-
Ok, great news, I also removed the --em-config arg now (in addition to the
--cache arg) and it works perfectly, this simplifies my cmake toolchain
setup a lot. I'm passing in the absolute path to the directory where the
emcc etc... tools are located, and in the cmake toolchain file set the
comp
> I really want to stop people from trying to do this. I'd much rather
the PATH was way one finds emscripten. e.g. `which emcc`. Failing that
an environment variable.
What about having several emsdk installations side by side though, without
any of them being the "default version".
But i
On Wed, May 20, 2020 at 6:55 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> I did not know that. That sounds like a much better approach anyway :-)
>
I'll hold off changing any of this until you can make your change
downstream. Can you let me know when
I did not know that. That sounds like a much better approach anyway :-)
On Wed, May 20, 2020 at 5:21 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
>
>
> On Wed, May 20, 2020 at 2:12 PM 'Steven Johnson' via emscripten-discuss <
> emscripten-discuss@googlegroup
On Wed, May 20, 2020 at 2:12 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> Halide uses the EM_CONFIG variable in its build script.
>
> The reason for this is that we need to ensure that LLVM_ROOT points to the
> specific version of LLVM being used by th
Halide uses the EM_CONFIG variable in its build script.
The reason for this is that we need to ensure that LLVM_ROOT points to the
specific version of LLVM being used by the rest of Halide. (Having these
out of sync can cause amusingly bad things to happen.) We slurp in the
default ~/.emscripten c
Passing a filename as --em-config or in EM_CONFIG will continue to work
yes. Thats the plan.
By the way if you use `emsdk --embedded` these days it should just work to
call emcc without `--em-config`. enscripten now knows to look for it
config relative to itself (firstly its own directory and t
> On May 20, 2020, at 12:28, Floh wrote:
>
> PS: I'm depending on the --em-config option (because I'm installing the emsdk
> with --embedded),
> but I'm passing in a regular string, not some sort of python expression).
>
Did you not see this in another thread?
> We have made a number of cha
PS: I'm depending on the --em-config option (because I'm installing the
emsdk with --embedded),
but I'm passing in a regular string, not some sort of python expression).
Are you going to remove the entire --em-config option, or just that it is
evaluated as a python string?
I'm fine with both, a
Good riddance ;)
That reminds me that the .emscripten file is also a python script which
must be evaluated with a python interpreter to make any sense of the content
For instance:
import os
emsdk_path = os.path.dirname(os.environ.get('EM_CONFIG')).replace('\\', '/')
...
Are there any plans on
emscripten has a feature where you can avoid using a config file
completely and instead pass a python literal in the EM_CONFIG
environment variable or `--em-config` command line.
e.g. `emcc --em-config="`
As part of routine cleanup I'm hoping to be able to remove this
feature and allow the code
25 matches
Mail list logo
