-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue #1037
[bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue #1037
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a reasonable fix to me. Do we need to prefix this command with the node executable, or does the #! work well enough?
I tested this locally on my Linux box and in a Linux RBE instance and it seems to work as is. |
If it works, I think it would be safer to do |
I tried that out and it appears to have worked. |
…pten-core#1037) * [bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue * space * specify node_js
* [bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue (emscripten-core#1037) * [bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue * space * specify node_js * 3.1.10 (emscripten-core#1046) * Optimize sandbox performance (emscripten-core#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 (bazelbuild/bazel#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. (emscripten-core#1052) * Using bazelisk on macOS CI (emscripten-core#1049) * Explicit outputs for wasm_cc_binary (emscripten-core#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 (emscripten-core#1053) * 3.1.12 (emscripten-core#1054) * 3.1.13 (emscripten-core#1055) * [bazel] Add additional files necessary for building with closure and on RBE (emscripten-core#1057) * 3.1.14 (emscripten-core#1061) * 3.1.15 (emscripten-core#1066) * Pin `latest` to a specific version for arm64-linux (emscripten-core#1065) Fixes: emscripten-core#1040 * 3.1.16 (emscripten-core#1071) * 3.1.17 (emscripten-core#1076) * Exclude msys from path fix function. (emscripten-core#1078) Fixes: #911 * 3.1.18 (emscripten-core#1081) * 3.1.18 * Update LLVM include path in Bazel files * Version 3.1.18-2 (emscripten-core#1083) 3.1.18 had a bad release binary on ARM64 Mac so push an updated version of the release. * 3.1.19 (emscripten-core#1090) * Add EMSDK_QUIET to make emsdk_env less chatting (emscripten-core#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 (emscripten-core#1095) * Add double-quotes to allow spaces in path (emscripten-core#1097) * 3.1.21 (emscripten-core#1101) * Update latest-arm64-linux to 3.1.21 (emscripten-core#1102) * Update XCode version on CircleCI (emscripten-core#1103) 12.2 is being deprecated * 3.1.22 (emscripten-core#1107) * 3.1.23 (emscripten-core#1111) * Avoid exporting EM_CONFIG for modern SDK versions (emscripten-core#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 (emscripten-core#1115) * 3.1.24 (emscripten-core#1122) * 3.1.25 (emscripten-core#1130) * [bazel] Switch to platforms-based toolchain resolution (emscripten-core#1036) * remove "name" attribute from bazel rules (emscripten-core#1131) * 3.1.26 (emscripten-core#1134) * Update remote_docker version in CircleCI config (emscripten-core#1117) 20.10.17 is the current default. * docker image: Change base to Ubuntu 22.04 LTS (jammy) (emscripten-core#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 (emscripten-core#1139) * Use constants for fixed paths. NFC (emscripten-core#1140) * Add standalone_wasm feature to bazel emscripten_toolchain (emscripten-core#1145) * 3.1.28 (emscripten-core#1149) * Upgrade to rules_nodejs 5.8.0 (emscripten-core#1150) Fixes emscripten-core#1020 * 3.1.29 (emscripten-core#1160) * Pin Windows CI to Bazel 5.4.0 (emscripten-core#1163) * Remove reference to fastcomp-latest. NFC (emscripten-core#1164) fastcomp can only be install using explicit versions names so this name doesn't work. * Remove fastcomp SDK and fastcomp build rules. NFC (emscripten-core#1165) Folks that want to work with fastcomp will now need to use an older checkout of emsdk. * 3.1.30 (emscripten-core#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>
When trying to compile using emscripten/emsdk on Bazel's remote executors, I ran into an error like:
By looking at the remote execution logs (e.g. appending
--execution_log_json_file=/tmp/execlog.json
to my Bazel command), I was able to figure out that Bazel was not preserving symlinks that were created by npm install, but rather uploading the linked file in place of the symlink.Instead of uploading
it was uploading
Then, when executing
node_modules/.bin/google-closure-compiler
, it would try to loadnode_modules/.bin/lib/utils.js
and not be able to find it.To work around this issue, we can bypass the symlink and run the google-closure-compiler/cli.js ourselves, which is successfully able to load the lib/utils.js and all other dependent files.
#883 is possibly a related issue