Additionally removes the `alias` and `only_alias` arguments and adds a
single `tag` argument - this makes it clear about the tag being pushed
to.
Fixes: #1631
Add links to CMake 4.2.0-rc3 into the manifest, and a mechanism inside
emsdk.py to look up an installed/activated CMake tool.
This enables a simple way to run `emsdk install cmake-4.2.0-rc3-64bit`
to acquire the CMake dependency needed for e.g. compiling LLVM and
Binaryen. This removes one manual setup item for setting up Emscripten
from source.
When `emsdk install foo` would fail on Windows, the return code would
get ignored since there were later commands in the script file.
To fix that, capture the error code from the emsdk call, and output that
as the final return code.
Also a drive-by Python path fix, which seemed to be out of date in the
.ps1 file.
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.
`C:\Python312\python.exe` is already in the path by default.
We no longer need to set this special path or environment variable. In
fact this code was doing nothing since it was adding the end of the PATH
so the system python was already coming first.
This PR adds the `publish-docker-image-multiplatform` CI job step that
pushes a multi-platform docker image when a new tag is created. #1211
Unfortunately, this is not as simple as pushing two images targeting
different platforms to the same tag. There are a couple of ways to
create a multi-platform image:
- Using `docker buildx` to build images for all platforms. To do this
images targeting non-native platforms would need to be built using QEMU
(slower), a remote machine or cross-compilation.
- Building and publishing platform-specific images
`emscripten/emsdk-x64`, `emscripten/emsdk-arm64` and then creating a
manifest that links to these images. This is the simpler solution to
implement, and is what this PR does.
Tested with CircleCI on my fork. See the pushed images at
[radiantly/emsdk ·
DockerHub](https://hub.docker.com/r/radiantly/emsdk/tags)
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.
The `-0` and `-1` suffixes here are not part of the install path which
only based on the `id` and `version` of the tool. e.g:
```
{
"id": "python",
"version": "3.9.2",
"bitness": 64,
"arch": "x86_64",
"windows_url": "python-3.9.2-1-embed-amd64+pywin32.zip",
"activated_cfg": "PYTHON='%installation_dir%/python.exe'",
"activated_env": "EMSDK_PYTHON=%installation_dir%/python.exe"
},
```
Here we have a `-1` in the archive name, but that is not included in the
version which is used to construct the install path.
Fixes: #1570
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.
This migrates the bazel integration to the new Bazel dependency system
"bzlmod". bzlmod is becoming mandatory this year (see second sentence
here: https://bazel.build/external/migration).
This is a backwards incompatible migration, directly removing the old
WORKSPACE based approach. Users will have to change how they depend on
bzlmod, however I assume pretty much every user will be happy about it,
because they are forced to use bzlmod anyway or add extra flags to
continue to build with newer Bazel versions. Given that users normally
depend on specific git commits in the old system, they won't be hit with
this until they decide to upgrade emsdk.
The basic principle here is simple: I took everything that WORKSPACE did
and searched an alternative in bzlmod. Some interesting bits:
- We have less worries about multiple versions and people depending on
emscripten multiple times in different ways. This is resolved by the new
system: Bazel first iterates through the MODULE.bazel files recursively,
then finds the minimum version needed for each module and then executes
the module extensions that define repos exactly once at that version. So
no more ifs needed to detect multiple inclusions.
- A bunch of nodejs stuff moves to MODULE.bazel, because that is how the
nodejs module works now. As their module extension gets executed only
once you need to declare everything that you could need before that in
the MODULE.bazel file. A side effect of that is that we have to make a
fake repository when emscripten doesn't have an arm64 binary for linux,
because we can't actually figure that out in MODULE.bazel, so we have to
declare that it always exists and then create one in all cases.
There is a bunch of autoformatter changes in here as well, I could try
to revert them if you prefer.
Closes#1509
