Fabian Meumertzheim

@brandjon This would be pretty useful to have and looks simple enough, would you be available for a review?

While I like the direction, what's the reason for not registering a toolchain per OS/architecture with `--incompatible_enable_proto_toolchain_resolution` plus the existing source-based toolchain last? That would also provide a natural opt-in...

That's a pretty decent approach. The only downside I see is that users may be led to (mistakenly) believe that they should depend on `protobuf-linux-x86_64` directly when they see it...

Bazel doesn't expose the symlink prefix to rules and in its exec root always uses `bazel-out`, which is also the source of these paths in nogo output. You could file...

I'm torn. rules_go is definitely the odd one among the rulesets with its naming scheme, but given the subtle issues and the best practices that @linzhp mentioned, I don't know...

Could you add a test for this under `tests/core/cgo`? It doesn't have to be a full end-to-end test, but perhaps you could set some `--copts` that are turned into absolute...

Thanks for the very thorough execution!

The header file should be part of the `CcInfo` provider returned by the `go_binary` target. You can inspect it with `bazel cquery --output=starlark --starlark:expr='providers(target)' //:target`. The header file is not...

The table is obsolete with Bzlmod as that allows either module to define a minimum version requirement on the other. We should drop it.

We have moved away from "injecting" third-party dependencies into your build as that only leads to trouble down the road. You can add a dependency on grpc like you would...