-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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: remove rules_cc #19760
bazel: remove rules_cc #19760
Conversation
CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to |
Hoping we're good here now that we're on 5.x, because we were waiting for some upstream change there |
this is breaking due to gcc linking issues ERROR: /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/external/com_google_protobuf/BUILD:513:10: Linking external/com_google_protobuf/protoc failed: (Exit 1): gcc failed: error executing command not sure of the exact cause, but as discussed offline i think removing |
96a5e4e
to
d0d92e0
Compare
5dea829
to
0de2211
Compare
0de2211
to
b22d658
Compare
I think I got to the bottom of that and updated the description accordingly, we'll see how CI feels |
b22d658
to
d883942
Compare
Depends on #20814 |
The plans for bazel to move to rules_cc have been postponed without any communication. There's no value to us in using this right now, but it will be trivial to re-adopt in the future if needed. But it has the downside of using a fork of bazel's crosstool, that has to be updated independently of bazel, which doesn't always happen as improvements are made. More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
d883942
to
050715d
Compare
This is for the same purpose as action_env except for host actions. This is required for C++ toolchain setup which discovers linkers in the cc configuration which uses PATH, but then host actions didn't use PATH because of --incompatible_strict_action_env, so gcc couldn't discover the `-fuse-ld=lld` path that was setup during the configuration. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
050715d
to
bd02165
Compare
/retest |
Retrying Azure Pipelines: |
/retest |
Retrying Azure Pipelines: |
Ok this is ready for review! The key here was to update buildifier to no longer try to enforce using rules_cc (they used to but flipped the default since things have stalled), and to pass through the host_action_env to make sure the setup uses the right tools |
Always like deps removal 👍 /lgtm deps |
bump |
Both of these projects are stalled on the bazel side, and these just pass through to the native rules anyways. I'm removing rules_cc from envoy as well envoyproxy/envoy#19760 so this mirrors that. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
Both of these projects are stalled on the bazel side, and these just pass through to the native rules anyways. I'm removing rules_cc from envoy as well envoyproxy/envoy#19760 so this mirrors that. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
Both of these projects are stalled on the bazel side, and these just pass through to the native rules anyways. I'm removing rules_cc from envoy as well envoyproxy/envoy#19760 so this mirrors that. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
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.
LGTM, thanks!
Following this PR, a few of us have started seeing differences between running the check_format.py tool with docker and without. When running check_format using docker ( It seems that after this PR the |
Can you update buildifier locally? There was a default flip that we're relying on that I update CI for. I can probably also bake that into the script to avoid this issue for older versions. Ideally we would start vendoring buildifier to avoid this. |
Upgrading buildifier fixed this, thanks! |
Both of these projects are stalled on the bazel side, and these just pass through to the native rules anyways. I'm removing rules_cc from envoy as well envoyproxy/envoy#19760 so this mirrors that. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
Both of these projects are stalled on the bazel side, and these just pass through to the native rules anyways. I'm removing rules_cc from envoy as well envoyproxy/envoy#19760 so this mirrors that. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
Both of these projects are stalled on the bazel side, and these just pass through to the native rules anyways. I'm removing rules_cc from envoy as well envoyproxy/envoy#19760 so this mirrors that. Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
The plans for bazel to move to rules_cc have been postponed without any communication. There's no value to us in using this right now, but it will be trivial to re-adopt in the future if needed. But it has the downside of using a fork of bazel's crosstool, that has to be updated independently of bazel, which doesn't always happen as improvements are made. More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150 This also required a `--host_action_env` addition to mirror the variables we pass through to actions in general. This is required because C++ toolchain setup which discovers linkers in the cc configuration which uses PATH directly, but then host actions didn't use PATH because of --incompatible_strict_action_env, so gcc couldn't discover the path of lld even though `-fuse-ld=lld` was passed. Fixes envoyproxy#16608 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
The plans for bazel to move to rules_cc have been postponed without any
communication. There's no value to us in using this right now, but it
will be trivial to re-adopt in the future if needed. But it has the
downside of using a fork of bazel's crosstool, that has to be updated
independently of bazel, which doesn't always happen as improvements are
made.
More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150
This also required a
--host_action_env
addition to mirror the variables wepass through to actions in general. This is required because C++ toolchain
setup which discovers linkers in the cc configuration which uses PATH directly,
but then host actions didn't use PATH because of
--incompatible_strict_action_env, so gcc couldn't discover the path of lld even
though
-fuse-ld=lld
was passed.Fixes #16608
Signed-off-by: Keith Smiley keithbsmiley@gmail.com