Document future of this ruleset #86
Labels
P3
Accepted issue. Team is likely to fix this issue in the future, but no short-term promises are made.
Comments
|
Sure would be nice to get some clarification here to resolve whether we should be applying the lint rule from buildifier or not... |
|
There seem to be quite a few bazel design docs out there with uncertain statuses, including e.g. the dependencies overhaul and licensing rules documents. Sure would be nice if the public-facing ones included a line about their status, similar to PEPs. It does seem like the bazel native cc rules aren't going anywhere any time soon, though. |
limdor
added a commit
to limdor/rules_go
that referenced
this issue
Sep 9, 2021
Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc. However rules_cc was always saying that there is no need to use them yet. After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it. One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit: bazelbuild/rules_cc#91 bazelbuild/rules_cc#68 The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc. More information about the discussions: bazelbuild/rules_cc#86 bazelbuild/rules_cc#92 bazelbuild/buildtools#923 bazelbuild/buildtools#952 Fixes bazelbuild#2949
limdor
added a commit
to limdor/rules_go
that referenced
this issue
Sep 9, 2021
Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc. However rules_cc was always saying that there is no need to use them yet. After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it. One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit: bazelbuild/rules_cc#91 bazelbuild/rules_cc#68 The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc. More information about the discussions: bazelbuild/rules_cc#86 bazelbuild/rules_cc#92 bazelbuild/buildtools#923 bazelbuild/buildtools#952 Fixes bazelbuild#2949
achew22
pushed a commit
to bazelbuild/rules_go
that referenced
this issue
Sep 10, 2021
Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc. However rules_cc was always saying that there is no need to use them yet. After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it. One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit: bazelbuild/rules_cc#91 bazelbuild/rules_cc#68 The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc. More information about the discussions: bazelbuild/rules_cc#86 bazelbuild/rules_cc#92 bazelbuild/buildtools#923 bazelbuild/buildtools#952 Fixes: #2949
keith
added a commit
to keith/envoy
that referenced
this issue
Nov 12, 2021
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>
keith
added a commit
to keith/envoy
that referenced
this issue
Apr 21, 2022
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>
keith
added a commit
to envoyproxy/envoy
that referenced
this issue
Apr 27, 2022
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 #16608 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
lizan
pushed a commit
to envoyproxy/data-plane-api
that referenced
this issue
Apr 27, 2022
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/envoy#16608 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> Mirrored from https://github.com/envoyproxy/envoy @ 1edd65f80bd8ded5cb2c0ebeec818784ebd76bfb
ravenblackx
pushed a commit
to ravenblackx/envoy
that referenced
this issue
Jun 8, 2022
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>
oschaaf
pushed a commit
to maistra/envoy
that referenced
this issue
Oct 26, 2022
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/envoy#16608 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com>
comius
added
the
P3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This proposal: https://docs.google.com/document/d/1GW7UVo1s9X0cti9OMgT3ga5ozKYUWLPk9k8c4-34rC4/edit# suggests that rules_cc is going to at least stagnate in development as an internal to Bazel migration occurs.
It'd be useful to document at least some ideas of what the future for rules_cc might be so potential users understand whether they should be using this or
@bazel_tools//cpprules if they want to integrate with the Bazel starlark rules for C/C++The text was updated successfully, but these errors were encountered: