This is needed to allow custom rules and/or transitions on top of wasm_cc_binary (e.g. to workaround #972).
It's debatable whether .wasm is the correct executable target for non-standalone Wasm builds, but we don't have a way to differentiate those in wasm_cc_binary, and considering that this attribute isn't exported now, it shouldn't break anything.
* 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>
It breaks @emsdk in workspaces that have this feature enabled.
The following error appears when using the latest commit:
cc_toolchain '@emsdk//emscripten_toolchain:everything' with
identifier 'emscripten-wasm' doesn't define a tool path for 'dwp'
The following error appears after adding `emdwp` tool and scripts:
output '*.dwo' was not created
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
These days this argument really means `install_even_if_directory_exists`
(at least since #9300.
However by the time we call `download_and_unzip` we have already checked
that `is_installed()` is false so we know we want to install for sure.
If the installation directory already existed and contained the correct
contents we would never get as far as `download_and_unzip`.
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.
* Always output a tarball from cc_binary to simplify logic. This will change the result of --config=wasm builds that were previously outputting a single file.
* better to use early return here
* Always output a tarball from cc_binary to simplify logic. This will change the result of --config=wasm builds that were previously outputting a single file.
* better to use early return here
Co-authored-by: Mitch Foley <mitchfoley@chromium.org>
They were originally removed from emsdk_manifest.json in commit
12f1824ffb ("Remove Tools and SDKs
that do no longer work after migration from Mozilla to Google
hosting. (#395)").
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
