Earlier Node 18.20.3 LTS did not yet support Windows on ARM64 builds.
Node 20.18.0 LTS is released on
https://nodejs.org/en/blog/release/v20.18.0.
This update currently only affects the "compiled from source" builds,
and not the Google precompiled releases.
Without this, emrun web server will be left running after user code
quits the page abnormally without calling `exit()` (e.g. due to a page
awwsnap crash), and there are multiple processes in use by the browser.
emrun has a graceful fallback to weaker browser process detection when
psutil is not available, so this is easy to miss if not running emrun
with --verbose:
814ec05f74/emrun.py (L330-L339)
This PR add several features to release automation:
1. The existing tag-release job has an output that indicates whether the
triggering commit
is a release (i.e. whether it matches the regex)
2. The new followup job runs a new script which fetches the recent
emscripten-releases
revisions, reads the DEPS file from the 'latest' release in
emscripten-releases-tags.json
to find the corresponding emscripten revision and writes it into the
environment
2. The final step reads the emscripten revision from the environment and
creates a
workflow_dispatch event to run the tag-release.yml job on the emscripten
repo
The action runs the existing create_release.py script in a new mode
created for github actions. Rather than using local git commands, it
uses a public action for creating a PR in the repository. The action can
be triggered from the website or via the CLI tool, for example
gh workflow run create-release.yml -R emscripten-core/emsdk -F
lto-sha=abc123 -F nonlto-sha=234567
Node v18 is that current LTS release of node and v18.20.3 is the latest
release of v18.
This change means that emsdk is no longer installable on Ubuntu/Bionic
18.04, and we now require Ubuntu/Focal 20.04.
See: #1183Fixes: #1173
This script is (IMO) more readable, but the real reason for this change is that
it raises an error message when the binary package fails to download. (The shell
script silently generated a bogus hash instead, because the shell's `set -e`
builtin does not affect commands executing inside a $() context.
It seemed just as easy to rewrite the script in Python as to fix that.
This change also updates some outdated filename references.
* Support Bazel builds on Apple silicon
* Add sha_mac_arm64 hash for 3.1.3
* Configure node_repositories in emscripten_deps.bzl
* Add mac arm64 to bazel workspace update script
Co-authored-by: Matthew Soulanille <matthew@guppy.home>
The newer versions of eslint require 14.17.0 or above. This
updates our node version to the latest in the 14.XX series.
I don't expect any user-visible changes.
Apparently 10.11 is no longer good enough to run the latest version of
binaryen. Specifically since binaryen switched to using std::variant it
now fails to build with this set to 10.11.
This is also the version used on the emscripten-releases CI which builds
the emsdk binaries:
https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#673
* Makes provided bazel rules look up @emsdk workspace instead of local workspace
* Uses system-specific emscripten binaries instead of defaulting to linux
* Provides macros for loading emsdk dependencies (nodejs and emscripten binaries)
* Unhardcodes paths in bazel rules and .sh wrappers
* `update_bazel_workspace.sh` now updates `revisions.bzl`
* `emscripten_deps()` can be fed with specific emscripten version
* Adds external usage test
Addresses #650 and #696
* Fix support for Apple M1. Node.js will still run via Rosetta 2 emulation since they do not yet have M1 support, but Python, LLVM, Emscripten and Binaryen will be native.
* Update M1 python version and URL
* Remove .gitignore additions
* Move python first in the manifest (#441)
* Use macosx-version-min when building python
* Update Intel macOS python package name
This is done by detecting the 40 character git sha in the SDK version
and creating a new set of tools based on this SHA. This works for any
command that uses expand_sdk_name (i.e. install activate and update) but
it wont show up in the output of `list`.
For example:
./emsdk install sdk-releases-upstream-b0cfdb236483b6828ee2e3f263fd94f011ed1863-64bit
Or just:
./emsdk install releases-upstream-b0cfdb236483b6828ee2e3f263fd94f011ed1863
For Java we use the value in the config file so it doesn't need to be in
the PATH.
For python, all our tools should launch via scripts that check for
EMSDK_PYTHON so having python in the PATH for emsdk users should not be
needed.
The motivation for this is that we don't want to clobber any existing
python or java versions that users might already have in their PATH.
This is the easy part of #705.
