This repository was archived by the owner on Apr 23, 2026. It is now read-only.
Repository navigation
Replies: 10 comments 1 reply
|
Migration advice: References to |
0 replies
|
rules_go: |
0 replies
|
rules_python: was fixed by bazel-contrib/rules_python#1577 and released in 0.32.0 |
1 reply
|
rules_ts: already fixed in aspect-build/rules_ts#608 - Released in v2.4.0 |
0 replies
|
protobuf itself: protocolbuffers/protobuf#17075 |
0 replies
|
I am not sure if this is the right place to report this issue but I found that |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This flag, introduced in Bazel 7 and advertised in the 6.0.0 release of rules_proto, allows users to avoid building the
cc_binarytarget@com_google_protobuf//:protocfrom source. This makes builds faster, reduces warnings spam in the Bazel log, and in cases where a codebase has no C++ code, it removes the dependency on a functional C++ toolchain.However, as long as any hard-coded references to
@com_google_protobuf//:protocare reachable via the dependency graph, the benefit of the flag is negated.End-users are the ones affected, but are not in a position to fix: they'll need to discover these bad dependency edges, isolate where the problem should be addressed, and find/file an issue on some ruleset. This discussion is meant to collect some practices for doing this, and a list of known issues.
To find why you depend on protoc:
bazel cquery 'somepath("//...", "@com_google_protobuf//:all")'To prevent protoc compilation from source (and grpc while we're at it) add to
.bazelrc:FYI @fmeum and @jiawen who are helping to facilitate the migration.
All reactions