-
Notifications
You must be signed in to change notification settings - Fork 232
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
Add the ability to define toolchains that are compiled locally #1028
base: main
Are you sure you want to change the base?
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Hi @jsharpe, wondering if this would be the right approach to selectively build toolchains no-remote or if you'd recommend another alternative? (Hoping to not have to maintain a fork and rather ship upstream) |
I think the way to do this would be via a string_flag (https://docs-legacy.aspect.build/bazelbuild/bazel-skylib/1.0.3/docs/common_settings.html#string_flag) that then conditionally adds the tag from the flag into the existing toolchain targets? |
appreciate the suggestion @jsharpe! However, I had initially tried that (link to original change) and it seems to be a limitation of bazel that I'm not able to add to "no-remote" to the tag in the
|
I know you're a busy person, but wanted to bump this @jsharpe 😅 |
I think you should be able to do this via the following diff:
Then to use it all you need to pass is |
@jsharpe Appreciate the diff, but after applying this diff, I received the error I looked into it and it seems this select for tags doesn't seem to be possible currently? |
following up here 😅 . Given that we're unable to add dynamically to toolchains, wondering if you'd had any other suggestions or to perhaps go with original changes @jsharpe ? |
My opinion is that this probably doesn't really belong here - its a workaround for a broken RBE FUSE implementation that doesn't preserve the posix semantics of the files that are input to the build. |
I’m not really familiar with remote execution so can’t be of much use here, I’m afraid 😔 |
When building make toolchain on remote execution, autoconf has a sanity check which complains due to system clock check. Given that our remote executors are FUSE based, the way to resolve this would be to build the make toolchain which cmake rule is dependent upon to run locally.
ERROR: /home/ryang/.cache/bazel/_bazel_ryang/d74806228f9a8a972e76dd6f55d51b26/external/rules_foreign_cc/toolchains/BUILD.bazel:137:10: BootstrapGNUMake external/rules_foreign_cc/toolchains/make [for tool] failed: (Exit 1): bash failed: error executing command (from target @rules_foreign_cc//toolchains:make_tool)