This PR adds downloadable firefox packages into emsdk.
The downloading of firefox will be done via the `mozdownload` pip
package, which simplifies the installation a lot.
Installing and activating a Firefox package will set up the
`EMTEST_BROWSER` variable, so running browser tests will then
automatically use the activated browser.
The oldest supported Firefox version by Emscripten is 65. So add that
version, and all ESR versions from 65 upwards, and the moving channels.
This allows people to go back and forth testing different versions of
interest.
Add support for a new command 'emsdk deactivate' that can be used to
remove a tool from the active list.
Since the big endian cross compile Node.js is added to `NODE_JS_TEST`
instead of `NODE_JS`, there needs to be a way to deactivate it for
regular runs.
This PR adds a `emsdk deactivate` command to enable doing that.
This PR adds support for
`./emsdk install node-nightly-64bit`
which finds the latest nightly node.js version and installs that. It is
a moving target, so the next day when a new nightly is produced,
reissuing `./emsdk install node-nightly-64bit` will install the newer
published version.
Also, this PR adds a fixed 22.18.0 version for the cross compilation
s390x Node.js target as well. On an x64 Linux system, this allows
running
`./emsdk install node-big-endian-crosscompile-22.16.0-64bit`
to install the big endian Node.js. This greatly simplifies the steps at
https://github.com/emscripten-core/emscripten/compare/main...juj:emscripten:bigendian_test_suite#diff-c36b90121be240017fa490a1c00e63e47fa3235f5c1be0593e2b7502d017c778R9985-R10000
and enables a trivial way to switch between LE and BE Node.js versions
for testing.
CC @slavek-kucera
Previously, if one used e.g. command
```
emsdk install --override-repository emscripten-main-64bit@https://github.com/juj/emscripten/tree/my_own_emscripten_branch emscripten-main-64bit
```
then the overridden installation would create a git clone from
`juj/emscripten`, and that clone would be located under the default
remote name `origin`.
This would prevent being able to switch between overrides on subsequent
`emsdk install` commands. I.e. it would then not be possible to later do
a default
```
emsdk install emscripten-main-64bit
```
command without an override, since the remote name `origin` would point
to `juj/emscripten` instead of `emscripten-core/emscripten`.
This PR changes the naming scheme of `git clone`s when
`--override-repository` is used, to name the clones with remote names
from the override, so in the above case, the clone would appear under
remote name `juj` and not `origin`.
This enables flipping between multiple `emsdk install` commands in the
same checkout, without needing to nuke the installed directory in
between.
This enables me to run experiments like
github.com/emscripten-core/emscripten/pull/25025 locally on my CI,
without needing to merge them upstream to become available.
Update Python to 3.13.0 and add support to Windows on AMD64. Rewrite
packaging of pywin32 because it is no longer shipped via separate binary
installers, but has migrated to use pip.
Turns out this is what was causing the OOM when building binaryen since
we were clobbering the EMSDK_NUM_CORES environment variable by mistake.
See #1429
I faced the same issue mentioned in #1299, this PR fixes the issue by
taking in account specific `set` and `unset` syntax for Fish shell.
The post install instruction (i.e : `./emsdk activate latest`) provides
wrong instructions in Fish shell and Cshell cases.
This should be fixed by this PR too, although the code is a bit
redundant and it could be more cleaner.
This is a bit of a hack but I can't think of another way to do it.
Basically when downloading SDKs, we first try the new `.xz` extension.
If that fails, we fall back to the old `.tbz2`. Both these first two
download attempts we run in "silent" mode. If both of them fail we
re-run the original request in non-silent mode so that the error message
will always contain the original `.xz` extension.
See #1235
The first time around `node` was being correctly added to the PATH, but
the second time around this code was observing the emsdk copy of node
in the PATH and assuming it could be skipped.
Fixes: #1240
If the user already has a version of node in their PATH don't clobber
it. This doesn't effect emscripten since the version of node we use
there is controlled via the config file, not via PATH.
Part of fix for #705.
We have an existing `version_key` helper function for sorting versions.
It also does a better job, producing output like:
```
All recent (non-legacy) installable versions are:
3.1.31
3.1.31-asserts
3.1.30
3.1.30-asserts
3.1.29
3.1.29-asserts
```
Rather than:
```
All recent (non-legacy) installable versions are:
3.1.31
3.1.30
3.1.29
3.1.28
3.1.27
```
(with -assert versions listed after 3.1.0)
* Add support for Visual Studio 2022 and migrate to using cmake --build when building on Windows. Leverage the VS2019 MSBuild 'Multi-ToolTask' feature CL_MPCount to saturate project builds properly to 100% CPU usage so building LLVM builds different cpp files in parallel. Clean up some code duplication around Visual Studio support.
* flake
* Work around Linux bot not having 'cmake --build . -j' flag.
Newer versions of emscipten, starting all the way back in 1.39.13, can
automatically locate the `.emscripten` config file that emsdk creates so
there is no need for the explicit EM_CONFIG environment variable. Its
redundant and adds unnessary noisce/complexity.
Really, adding emcc to the PATH is all the is needed these days.
One nice thing about this change is that it allows folks to run
whichever emcc they want to and have it just work, even if they have
configured emsdk. Without this change, if I activate emsdk and I run
`some/other/emcc` then emsdk's `EM_CONFIG` will still be present and
override the configuration embedded in `some/other/emcc`.
e.g. in the same shell, with emsdk activated, I can run both these
commands and have them both just work as expected.
```
$ emcc --version
$ /path/to/my/emcc --version
```
Without this the recommended way to silence emsdk_env was to pipe its
stderr to /dev/null.. but then you also loose potentially useful error
message.
Fixes: #946
* Pass -DENABLE_WERROR=0 when building Binaryen
We are experiencing an issue at our Unity CI with building Binaryen: https://github.com/WebAssembly/binaryen/issues/4588
It seems that for end users, disabling -Werror is a good general measure to enable wider chance of success to build. Emsdk installations are unlikely to be used by Binaryen developers to iterate on Binaryen development, so it is not necessary there?
* Flake
* Enable building LLVM with about-to-be deprecated toolchains for best chance of succeeding with the build.
* Shorten line length
* Adjust to 80 columns
