Skip to content

feat(toolchain): support --incompatible_enable_proto_toolchain_resolution - #428

Open
kangnak wants to merge 1 commit into
stackb:masterfrom
kangnak:protoc-toolchain-resolution
Open

feat(toolchain): support --incompatible_enable_proto_toolchain_resolution#428
kangnak wants to merge 1 commit into
stackb:masterfrom
kangnak:protoc-toolchain-resolution

Conversation

@kangnak

@kangnak kangnak commented Aug 13, 2026

Copy link
Copy Markdown

Fixes #402

Problem

//toolchain:compiled hardcodes @com_google_protobuf//:protoc. Because bzlmod repo mappings are per-module, a user who swaps @com_google_protobuf for a prebuilt protoc repo — e.g. with toolchains_protoc — only changes the mapping of their own root module. build_stack_rules_proto still resolves @com_google_protobuf to the protobuf module, so protoc is built from source. With the --per_file_copt guards recommended by toolchains_protoc, that surfaces as:

gcc: error: unrecognized command-line option '--PROTOBUF_WAS_NOT_SUPPOSED_TO_BE_BUILT'

Change

When --incompatible_enable_proto_toolchain_resolution is enabled, proto_compile now sources protoc from the registered proto toolchain (@rules_proto//proto:toolchain_type) — the same toolchain proto_library itself uses, and the one toolchains_protoc registers.

Resolution order:

  1. the protoc rule attribute, if set
  2. the proto toolchain, when the flag is enabled and one is registered
  3. the //toolchain:protoc toolchain

With the flag disabled, behavior is unchanged: //toolchain:protoc remains a mandatory toolchain of the rule. With the flag enabled, both toolchain types are declared optional, so register_toolchains("@build_stack_rules_proto//toolchain:standard") is no longer required — and keeping it registered is harmless, since the proto toolchain takes precedence.

The compile action also passes the resolved FilesToRunProvider as a tool now (instead of just the executable File), so runfiles of a protoc wrapper are available to the action.

Files

  • toolchain/toolchain.bzl — adds INCOMPATIBLE_ENABLE_PROTO_TOOLCHAIN_RESOLUTION, use_protoc_toolchains() and find_protoc().
  • rules/proto_compile.bzl — uses the helpers. get_protoc_executable() is kept as a deprecated shim.
  • docs/TOOLCHAINS.md — documents the flag and a toolchains_protoc setup.

Testing

A stub toolchain of type //toolchain:protoc whose protoc always exits non-zero was registered via --extra_toolchains, to prove which protoc is actually selected:

Configuration Result
flag off stub protoc used → build fails (legacy behavior preserved)
flag on proto toolchain wins → build succeeds
flag on, proto toolchain type unregistered falls back to //toolchain:protoc

Also verified:

  • bazel build //... and bazel test //... pass (29/29, including //tools:buildifier.check)
  • bazel build --incompatible_enable_proto_toolchain_resolution //example/... //google/... passes

🤖 Generated with Claude Code

…tion

When --incompatible_enable_proto_toolchain_resolution is enabled, resolve
protoc from the registered proto toolchain (@rules_proto//proto:toolchain_type)
rather than from //toolchain:protoc.

The //toolchain:compiled toolchain hardcodes @com_google_protobuf//:protoc.
Since bzlmod repo mappings are per-module, a user that swaps
@com_google_protobuf for a prebuilt protoc repo (e.g. via toolchains_protoc)
only changes the mapping of their own root module; this ruleset still resolves
@com_google_protobuf to the protobuf module and protoc gets built from source.

Resolution order for proto_compile is now:

  1. the 'protoc' attribute, if set
  2. the proto toolchain, when the flag is enabled and one is registered
  3. the //toolchain:protoc toolchain

With the flag disabled, behavior is unchanged: //toolchain:protoc stays a
mandatory toolchain of the rule. With the flag enabled, both toolchain types
are optional, so registering @build_stack_rules_proto//toolchain:standard is no
longer required (registering it remains harmless).

The compile action now passes the resolved FilesToRunProvider as a tool, so
runfiles of a protoc wrapper are made available to the action.

Fixes stackb#402

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Question about precompiled protoc

1 participant