* Fix native Closure Compiler to work. Reverts my earlier PR #803 which was a great mistake, as it caused Emscripten to silently fall back to Java version of the Closure Compiler. After this PR, Closure Compiler will work on user platforms that do not have Java installed. Also forcibly remove Java version of Closure Compiler on systems where installing the native version succeeds, in order to save on code size.
* Add note to bug
* Improve google-closure-compiler-java uninstall.
* Read Closure version from Emscripten repository
* Skip native google-closure-compiler install when it is not present in the emscripten branch in package.json
* Print error
* Cache git executable search into a variable. This helps reduce noise in the verbose debug logging output messages when EMSDK_VERBOSE=1 is enabled.
* Flake
* Mark cached_git_executable global
Regarding the change to `content_exists`, we only support tools that
are directories full of files, there is no such thing as a tool that
is just a single file and not a directory.
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.
