If the user already has a version of node in their PATH don't clobber
it. This doesn't effect emscripten since the version of node we use
there is controlled via the config file, not via PATH.
Part of fix for #705.
* [bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue (#1037)
* [bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue
* space
* specify node_js
* 3.1.10 (#1046)
* Optimize sandbox performance (#1045)
* Optimize sandbox performance
Link just the files needed to compile, link, or archive, rather than the entire directory tree. This drastically improves build times on macOS, where the sandbox is known to be slow (https://github.com/bazelbuild/bazel/issues/8230).
* Linux wants clang to link
* all_files not needed?
* Linux wants llc
* And llvm-ar
* Templated build_file_content
* include node modules glob with linker files. also some minor formatting fixes. (#1052)
* Using bazelisk on macOS CI (#1049)
* Explicit outputs for wasm_cc_binary (#1047)
* Explicit outputs for wasm_cc_binary
* Backwards compatibility
* data_runfiles restore
* restore test_bazel.sh
* Using wrong path on accident
* two separate rules for legacy support
* Added name attribute to wasm_cc_binary rule
* 3.1.11 (#1053)
* 3.1.12 (#1054)
* 3.1.13 (#1055)
* [bazel] Add additional files necessary for building with closure and on RBE (#1057)
* 3.1.14 (#1061)
* 3.1.15 (#1066)
* Pin `latest` to a specific version for arm64-linux (#1065)
Fixes: #1040
* 3.1.16 (#1071)
* 3.1.17 (#1076)
* Exclude msys from path fix function. (#1078)
Fixes: #911
* 3.1.18 (#1081)
* 3.1.18
* Update LLVM include path in Bazel files
* Version 3.1.18-2 (#1083)
3.1.18 had a bad release binary on ARM64 Mac so push an updated version of the release.
* 3.1.19 (#1090)
* Add EMSDK_QUIET to make emsdk_env less chatting (#1091)
Without this the recommended way to silence emsdk_env was to pipe its
stderr to /dev/null.. but then you also loose potentially useful error
message.
Fixes: #946
* 3.1.20 (#1095)
* Add double-quotes to allow spaces in path (#1097)
* 3.1.21 (#1101)
* Update latest-arm64-linux to 3.1.21 (#1102)
* Update XCode version on CircleCI (#1103)
12.2 is being deprecated
* 3.1.22 (#1107)
* 3.1.23 (#1111)
* Avoid exporting EM_CONFIG for modern SDK versions (#1110)
Newer versions of emscipten, starting all the way back in 1.39.13, can
automatically locate the `.emscripten` config file that emsdk creates so
there is no need for the explicit EM_CONFIG environment variable. Its
redundant and adds unnessary noisce/complexity.
Really, adding emcc to the PATH is all the is needed these days.
One nice thing about this change is that it allows folks to run
whichever emcc they want to and have it just work, even if they have
configured emsdk. Without this change, if I activate emsdk and I run
`some/other/emcc` then emsdk's `EM_CONFIG` will still be present and
override the configuration embedded in `some/other/emcc`.
e.g. in the same shell, with emsdk activated, I can run both these
commands and have them both just work as expected.
```
$ emcc --version
$ /path/to/my/emcc --version
```
* Use x64 version for Windows on Arm (#1115)
* 3.1.24 (#1122)
* 3.1.25 (#1130)
* [bazel] Switch to platforms-based toolchain resolution (#1036)
* remove "name" attribute from bazel rules (#1131)
* 3.1.26 (#1134)
* Update remote_docker version in CircleCI config (#1117)
20.10.17 is the current default.
* docker image: Change base to Ubuntu 22.04 LTS (jammy) (#1135)
Done to upgrade from CMake 3.16.3 to 3.22.1. CMake 3.21 or newer is needed to build the Qt 6.4.1 sources with emscripten.
Also update to libidn12 to resolve an "Unable to locate package libidn11" error.
* 3.1.27 (#1139)
* Use constants for fixed paths. NFC (#1140)
* Add standalone_wasm feature to bazel emscripten_toolchain (#1145)
* 3.1.28 (#1149)
* Upgrade to rules_nodejs 5.8.0 (#1150)
Fixes https://github.com/emscripten-core/emsdk/issues/1020
* 3.1.29 (#1160)
* Pin Windows CI to Bazel 5.4.0 (#1163)
* Remove reference to fastcomp-latest. NFC (#1164)
fastcomp can only be install using explicit versions names so this name
doesn't work.
* Remove fastcomp SDK and fastcomp build rules. NFC (#1165)
Folks that want to work with fastcomp will now need to use an older
checkout of emsdk.
* 3.1.30 (#1167)
* Bump emscripten to 3.1.30
* Bump clang version
* Do not include test directory
* Update eng/emsdk.proj
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
---------
Co-authored-by: Kevin Lubick <kjlubick@users.noreply.github.com>
Co-authored-by: Sam Clegg <sbc@chromium.org>
Co-authored-by: John Firebaugh <john.firebaugh@gmail.com>
Co-authored-by: walkingeyerobot <mitch@thefoley.net>
Co-authored-by: Ezekiel Warren <zaucy@users.noreply.github.com>
Co-authored-by: Heejin Ahn <aheejin@gmail.com>
Co-authored-by: Tim Ebbeke <Tim06TR@gmail.com>
Co-authored-by: Derek Schuff <dschuff@chromium.org>
Co-authored-by: Joel Van Eenwyk <joel.vaneenwyk@gmail.com>
Co-authored-by: Pierrick Bouvier <101587250+pbo-linaro@users.noreply.github.com>
Co-authored-by: Trevor Hickey <TrevorJamesHickey@gmail.com>
Co-authored-by: Fredrik Orderud <forderud@users.noreply.github.com>
Co-authored-by: Robbert van Ginkel <570934+robbertvanginkel@users.noreply.github.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
We have an existing `version_key` helper function for sorting versions.
It also does a better job, producing output like:
```
All recent (non-legacy) installable versions are:
3.1.31
3.1.31-asserts
3.1.30
3.1.30-asserts
3.1.29
3.1.29-asserts
```
Rather than:
```
All recent (non-legacy) installable versions are:
3.1.31
3.1.30
3.1.29
3.1.28
3.1.27
```
(with -assert versions listed after 3.1.0)
* Add support for Visual Studio 2022 and migrate to using cmake --build when building on Windows. Leverage the VS2019 MSBuild 'Multi-ToolTask' feature CL_MPCount to saturate project builds properly to 100% CPU usage so building LLVM builds different cpp files in parallel. Clean up some code duplication around Visual Studio support.
* flake
* Work around Linux bot not having 'cmake --build . -j' flag.
Newer versions of emscipten, starting all the way back in 1.39.13, can
automatically locate the `.emscripten` config file that emsdk creates so
there is no need for the explicit EM_CONFIG environment variable. Its
redundant and adds unnessary noisce/complexity.
Really, adding emcc to the PATH is all the is needed these days.
One nice thing about this change is that it allows folks to run
whichever emcc they want to and have it just work, even if they have
configured emsdk. Without this change, if I activate emsdk and I run
`some/other/emcc` then emsdk's `EM_CONFIG` will still be present and
override the configuration embedded in `some/other/emcc`.
e.g. in the same shell, with emsdk activated, I can run both these
commands and have them both just work as expected.
```
$ emcc --version
$ /path/to/my/emcc --version
```
Without this the recommended way to silence emsdk_env was to pipe its
stderr to /dev/null.. but then you also loose potentially useful error
message.
Fixes: #946
* Pass -DENABLE_WERROR=0 when building Binaryen
We are experiencing an issue at our Unity CI with building Binaryen: https://github.com/WebAssembly/binaryen/issues/4588
It seems that for end users, disabling -Werror is a good general measure to enable wider chance of success to build. Emsdk installations are unlikely to be used by Binaryen developers to iterate on Binaryen development, so it is not necessary there?
* Flake
* Enable building LLVM with about-to-be deprecated toolchains for best chance of succeeding with the build.
* Shorten line length
* Adjust to 80 columns
When doing a git clone of a branch, instead of doing a general git clone that first would check out the default (main/master) branch and then later doing a checkout to switch to the target branch, instead specify the `--branch` option to the clone command line to immediately clone and checkout the desired final branch.
This helps first checkout runtime performance on CIs, especially when using shallow clones (GIT_CLONE_SHALLOW option).
Also this sidesteps a really odd git clone issue we are currently seeing in our CI, where it is unable to `checkout` the googletest submodule in binaryen, but would fail saying "path not found".
* 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.
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`.
Radek Doulik
Radek Doulik
Sam Clegg
Larry Ewing
Radek Bartoň
Radek Bartoň
Ankit Jain
juj
Pierrick Bouvier
Tim Ebbeke
百地 希留耶
Greg Buchholz