| commit | 18ea0125fe8e932b2a3dcdcdbab70111f96d5e34 | [log] [tgz] |
|---|---|---|
| author | Alon Zakai <[email protected]> | Fri Jun 11 16:26:16 2021 |
| committer | GitHub <[email protected]> | Fri Jun 11 16:26:16 2021 |
| tree | 3e11f9acd5a5200ae482fc12707b8991dd4f6d7d | |
| parent | bd1212f3f2d6cd6d3b695057eae3a911c5309ea4 [diff] |
Switch Firefox testing to headless mode, and disable GL testing there (#14434) I cannot reproduce the errors in #14401 locally, so I investigated on the CI side. Looking at many failures, they are all in tests that use GL. And so a theory is that the odd graphics setup on CI is to blame somehow - perhaps the GL driver crashes firefox randomly. An update to those GL drivers could explain why this happens so frequently now. This PR switches us away from using that odd graphics setup, and instead to use headless mode. Headless mode does not support GL - that is why we avoided it before - but it seems like now we have no choice but to avoid GL tests on firefox. That must wait until firefox fixes https://bugzil.la/1375585 To confirm the theory here, I ran 8 runs of CI, and all tests passed, so I think this makes us stable again. The cost of not doing GL testing is significant, but I don't see an alternative. This PR marks more tests as needing GL hardware, that were missing that tag. This also disables emrun and posix tests. (That's just a very small number of tests, so it doesn't seem so bad.) The issue there is that something about headless mode doesn't mix well with wanting to start another firefox process, see the comment in the PR. It might be worth experimenting with killing the firefox process or something like that, but I think this could land first. This also returns us to testing Firefox dev edition, as before.
Main project page: https://emscripten.org
GitHub CI status: 
Chromium builder status: emscripten-releases
Emscripten compiles C and C++ to WebAssembly using LLVM and Binaryen. Emscripten output can run on the Web, in Node.js, and in wasm runtimes.
Emscripten provides Web support for popular portable APIs such as OpenGL and SDL2, allowing complex graphical native applications to be ported, such as the Unity game engine and Google Earth. It can probably port your codebase, too!
While Emscripten mostly focuses on compiling C and C++ using Clang, it can be integrated with other LLVM-using compilers (for example, Rust has Emscripten integration, with the wasm32-unknown-emscripten and asmjs-unknown-emscripten targets).
Emscripten is available under 2 licenses, the MIT license and the University of Illinois/NCSA Open Source License.
Both are permissive open source licenses, with little if any practical difference between them.
The reason for offering both is that (1) the MIT license is well-known and suitable for a compiler toolchain, while (2) LLVM‘s original license, the University of Illinois/NCSA Open Source License, was also offered to allow Emscripten’s code to be integrated upstream into LLVM. The second reason became less important after Emscripten switched to the LLVM wasm backend, at which point there isn't any code we expect to move back and forth between the projects; also, LLVM relicensed to Apache 2.0 + exceptions meanwhile. In practice you can just consider Emscripten as MIT licensed (which allows you to do pretty much anything you want with a compiler, including commercial and non-commercial use).
See LICENSE for the full content of the licenses.