Please test the new build infrastructure!

[Alon Zakai]

We have been working hard to replace the current build infrastructure with a new system. The new one will be faster, have better support for testing, and support the LLVM wasm backend (in fact this change is the last blocker for us switching to that by default). As of now you can start to test this out, if you do the following:

* get latest emsdk master

* ./emsdk install latest-releases-fastcomp

* ./emsdk activate latest-releases-fastcomp

* optionally add the directory to the path with: source ./emsdk_env.sh

That will install a new release tag, 1.38.33, from the new builders.

Note that there is no change to "latest" (or other modes) - this just adds this new "latest-releases-fastcomp". But after we are sure things work well, the goal is to make "latest-releases-fastcomp" replace "latest".

Please let us know if you see any issues with the emsdk or with using emcc from that install!

Notes:

 * You can replace "fastcomp" with "upstream" to use the LLVM wasm backend. We'll have a larger announcement about this soon.

 * The new builders don't download java yet, so closure compiler won't work (unless you install it yourself). Aside from that, things should work just like "latest".

- Alon

[Marc Fawzi]

Any visible performance or size improvements that we should look for or is this merely an architectural change?

--
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-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTNiAaFodxx3QJWp-SCdzSeqKfdjMO7K15WjaqKQUVn2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

The LLVM wasm backend change mentioned will bring advantages there, but the current change is just to switch the builders from the old mozilla infrastructure to the new chromium one.

This is a requirement for the wasm backend - as only the new builders support the wasm backend - but separate from it. In other words, using fastcomp on either the old builders ("latest") or the new ones ("latest-releases-fastcomp") should give you the same results.

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CACioZitxDLFFs1mtB4T0Tm4VaH%2B%2B3Z%3DBWUhvfxWy9kYfrWR5Qg%40mail.gmail.com.

[Александр Гурьянов]

I do not use emsdk scritps. Can I test this new builder by updating
all repos to incoming.

cd emscripten/
git fetch
git checkout origin/incoming

cd ../emscripten-fastcomp/
git fetch
git checkout origin/incoming
cd tools/clang
git fetch
git checkout origin/incoming
cd ../../build
make -j4

If it's enough? Thanks

пт, 24 мая 2019 г. в 07:51, Alon Zakai <alon...@gmail.com>:

> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQzOkKScWF1OsaEGXpx-h8KEgFsYCoyTudEx2vD2qr1dQ%40mail.gmail.com.

[Alon Zakai]

If you build yourself, then there is no difference for now, and using incoming on those repos is correct.

There will be a difference, though, with the LLVM wasm backend. For that, you will need to change repos and use upstream LLVM instead of fastcomp. We'll have an announcement soon with more details.

For now our goal is to switch just the builders for the emsdk. After that, we'll focus on switching to the new backend.

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVEBfa5rMV4yaLiehwYM50ahKFoxZMQBUgroFgfqxdV_MA%40mail.gmail.com.

[Shlomi Fish]

[resending]

Hi Alon,

On Thu, 23 May 2019 17:44:51 -0700
Alon Zakai <alon...@gmail.com> wrote:

> We have been working hard to replace the current build infrastructure with
> a new system. The new one will be faster, have better support for testing,
> and support the LLVM wasm backend (in fact this change is the last blocker
> for us switching to that by default). As of now you can start to test this
> out, if you do the following:
>
> * get latest emsdk master
> * ./emsdk install latest-releases-fastcomp
> * ./emsdk activate latest-releases-fastcomp
> * optionally add the directory to the path with: source ./emsdk_env.sh
>

trying that gives me many tinfo.5 warnings -
https://www.shlomifish.org/Files/files/text/emcc-fastcomp-latest-output.txt.xz

<<<
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/clang++:
/lib64/libtinfo.so.5: no version information available (required by
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/../lib/libLLVM-6.0.so)
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/clang++:
/lib64/libtinfo.so.5: no version information available (required by
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/../lib/libLLVM-6.0.so)
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/clang++:
/lib64/libtinfo.so.5: no version information available (required by
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/../lib/libLLVM-6.0.so)
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/clang++:
/lib64/libtinfo.so.5: no version information available (required by
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/fastcomp/3b8cff670e9233a6623563add831647e8689a86b/fastcomp/bin/../lib/libLLVM-6.0.so)

>>>

the result code seems to be working fine.

thanks!

[Alon Zakai]

Interesting, thanks Shlomi! We need to change something with our linking, it seems - we'll look into it.

Which OS is that on, btw?

- Alon

[Shlomi Fish]

On Fri, 24 May 2019 07:31:29 -0700
Alon Zakai <alon...@gmail.com> wrote:

> Interesting, thanks Shlomi! We need to change something with our linking,
> it seems - we'll look into it.
>
> Which OS is that on, btw?
>

mageia linux v7 x86-64.

Thanks!

> > the result code seems to be working fine.
> >
> > thanks!
> >
> > > That will install a new release tag, 1.38.33, from the new builders.
> > >
> > > Note that there is no change to "latest" (or other modes) - this just
> > adds
> > > this new "latest-releases-fastcomp". But after we are sure things work
> > > well, the goal is to make "latest-releases-fastcomp" replace "latest".
> > >
> > > Please let us know if you see any issues with the emsdk or with using
> > emcc
> > > from that install!
> > >
> > > Notes:
> > >
> > > * You can replace "fastcomp" with "upstream" to use the LLVM wasm
> > backend.
> > > We'll have a larger announcement about this soon.
> > > * The new builders don't download java yet, so closure compiler won't
> > work
> > > (unless you install it yourself). Aside from that, things should work
> > just
> > > like "latest".
> > >
> > > - Alon
> > >
> >
> >
> >

--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
List of Text Processing Tools - http://shlom.in/text-proc

Chuck Norris could have built the Roman Empire in a day. And it would have
taken him even less time to destroy it.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .

[Floh]

I'm testing with my cmake-based build setup and I'm having trouble with the new directory structure of the SDK.

I need to know the path to the emscripten installation in various places (among others, a cmake toolchain file), but as far as I can see, those files are now under a cryptic directory name:

fastcomp/3b8cff670e9233a6623563add831647e8689a86b/emscripten/emcc

Before it was something predictable like

emscripten/incoming/emcc

I don't want to "pollute" the global environment with environment or path variables (emcc is not in the path for instance), since I want to have different SDK versions side by side.

Is there any chance we can have a standardized or "predictable" directory structure? Maybe a link to the actual SDK directory with a common name?

Currently that's a bit of a show stopper for further testing since I would need to rethink my the entire emscripten integration into my build system.

I'm also getting some errors during installation:

Error downloading URL 'https://storage.googleapis.com/wasm-llvm/builds/osx/lkgr.json': HTTP Error 404: Not Found

Error parsing lkgr.json!

[Errno 2] No such file or directory: '/Users/floh/projects/fips-sdks/osx/emsdk-portable/upstream/lkgr.json'

Cheers,

-Floh.

[Alon Zakai]

Thanks for the feedback!

The reason we extract into a different directory is so that (1) you can have multiple builds and switch between them, and (2) when you install/activate a version, we know if we need to unzip it or not - if the directory exists and is populated, then we have nothing to do. Otherwise we'd always need to unzip the files. But yeah, I do see your point that it makes it harder to just use the build. However, when you do the "activate" step it populates the .emscripten file with the relevant paths - can you get it from there for your build system?

The lkgr.json warning should be fixed on emsdk master currently.

--
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-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fb29262a-bbad-4a29-b818-1d4ad861a5e1%40googlegroups.com.

[Floh]

> However, when you do the "activate" step it populates the .emscripten file with the relevant paths - can you get it from there for your build system?

Yes, I guess I can figure something out along those lines :)

I'm planning to rework my emscripten integration so that it plays better with the emsdk (e.g. I'm currently not supporting easily switching between SDK versions).

One thing that would be nice would be quering the current SDK path a'la the Xcode command line tools xcode-select and xcrun.

The xcode-select tool is a bit similar to "emsdk activate", I can make one of many installed macOS/iOS/tvOS... SDKs the active one for the other command line tools...

And xcrun has an option to show the currently active SDK path, for instance:

> xcrun --show-sdk-path

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

...and the output is in an "automation-friendly format", just the path and nothing else.

So something like this would be nice:

> emsdk show-sdk-path

/Users/floh/.../fastcomp/3b8cff670e9233a6623563add831647e8689a86b/emscripten/

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Alon Zakai]

Yeah, that might be useful - I opened https://github.com/emscripten-core/emsdk/pull/247 for further discussion. I also wonder if a fixed dir might be better actually, also mentioned there as a question.

- Alon

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fb29262a-bbad-4a29-b818-1d4ad861a5e1%40googlegroups.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-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/74cb536f-e540-4a18-ab77-53454ba73292%40googlegroups.com.

[Floh]

Ok, after mucking around for most of the day with cleaning up my build system integration I can say: "it works" (the "latest-releases-fastcomp" SDK version). I was expecting that the closure pass breaks, but looks like it works since I had a Java RTE "accidently" installed). I have only tested my sokol-samples so far, but these are quite "representative" I think.

I wrote down some feedback in this PR:

https://github.com/emscripten-core/emsdk/pull/248

Cheers,

-Floh.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fb29262a-bbad-4a29-b818-1d4ad861a5e1%40googlegroups.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+unsub...@googlegroups.com.