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`.
This is a working solution for generating a separate Emscripten cache.
Note that this requires an additional entry in the workspace as follows:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache()
```
When used like this, the default Emscripten cache will be used. However,
if the entry is as follows:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache(flags = ["--lto"])
```
Then embuilder will be called to build all system libraries and ports
(i.e., the `ALL` option to embuilder) with the LTO option enabled. This
can take awhile, so I have also made possible to specify which libraries
you want to build explicitly:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache(
flags = ["--lto"],
libraries = [
"crtbegin",
"libprintf_long_double-debug",
"libstubs-debug",
"libnoexit",
"libc-debug",
"libdlmalloc",
"libcompiler_rt",
"libc++-noexcept",
"libc++abi-debug-noexcept",
"libsockets"
]
)
```
Resolves#807, resolves#971, resolves#1099, resolves#1362, resolves
#1401
* Allows generation of audio worklet bootstrap js file
In order to allow users to generate the file, the allowed extension list in `link_wrapper.py` has been updated accordingly.
* adds audio worklet js to wasm_cc_binary too
---------
Co-authored-by: William Izzo <william.izzo@hey.com>
* (bazel) Set @platforms//os:emscripten for platform_wasm
* (bazel) Set @platforms//os:emscripten for platform_wasm
* (bazel) Set @platforms//os:emscripten for platform_wasm
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.
