local=True marks a repository rule to unconditionally re-execute anytime
bazel re-evaluates the workspace (almost every invocation) It works well
for processes that execute in <10ms, not large ones like the embuilder
cache generation.
I have tested this locally and it seems to work fine, but I'll be honest
that I don't understand the nuances of repository rules that well, nor
do I know much of anything about emscripten or the circumstances in
which the cache ought to be rebuilt.
I checked the `external/@emscripten_cache.marker` file that Bazel uses
to store the cache key for if it needs to re-evaluate, and changing any
of the options passed into register_emscripten_toolchains resulted in
the cache key changing, and it correctly resulted in the cache being
regenerated.
The big question I don't have the context to answer: are there files on
disk other than these two that need to be watched for changes, so the
repository rule should change if they change:
```
FILE:@@emscripten_bin_linux//BUILD.bazel
FILE:@@emsdk//emscripten_toolchain/default_config
```
The current way to derive the binary path relies on a specific name for
the nodejs repository. This blocks migrating to bzlmod, as bzlmod
prefixes repository directories with the module name that created them.
By asking bazel for the path instead we always get the correct path, so
we can work with both bzlmod and WORKSPACE based dependencies at the
same time.
The repository @nodejs, used in the build label, refers to nodejs for
the host platform and is generated by the following macro (wasn't too
obvious to me):
d19d695275/nodejs/repositories.bzl (L452)
This is some work towards solving #1509.
This finishes the work started in
https://github.com/emscripten-core/emsdk/pull/1388 by fixing CI. It
avoids a breaking change by:
* Using the latest rules_js 1.x.x version, instead of updating to
rules_js 2 (which removes support for bazel 5).
* Copying the contents of
[rules_js_dependencies](https://github.com/aspect-build/rules_js/blob/main/js/repositories.bzl)
instead of calling it, as the call would need to be added by users in
their `WORKSPACE` files
Context from the previous PR:
> Bazel's Node.js dependency comes from
[rules_nodejs](https://github.com/bazelbuild/rules_nodejs/). Previously,
bazel/deps.bzl was using rules_nodejs 5.8.0, released in 2022 and only
supported Node.js toolchains up to 18.12.1.
> This PR bumps rules_nodejs to latest 6.1.1. It also replaces
build_bazel_rules_nodejs with
[rules_js](https://github.com/aspect-build/rules_js), since npm_install
that bazel/emscripten_deps.bzl used was deprecated. The README of
rules_nodejs now recommends migrating to rules_js for everything other
than the Node.js toolchain:
(371e8cab15)
> Impetus
Our repo builds with Bazel and uses Emscripten and Node.js. Tried to
upgrade Node.js 18 to Node.js 20 and saw that emsdk didn't support
rules_nodejs 6+ in the same workspace.
Similarly, it's not possible to update to rules_js v2 in a workspace
that also references `emsdk`.
Update Node from 18.20.3 LTS to 20.18.0 in precompiled releases. This
does have an effect of retroactively updating Node version also to old
releases, but this is expected to be fine.
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
For commits created by the new create-release.yml workflow, we can add
the corresponding release tag. This only runs for changes to the tag
JSON file (and the workflow itself) and only acts on changes created by
the automation (so that it won't interfere if we want to do things
manually).
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
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.
