Add bazel targets for standalone plugin binaries

[bufdev]

Follow-up to #23736 and #13308 but with only Bazel targets added per feedback.

This PR adds targets to build protoc plugins for all the built-in plugins. This will result in the following binaries being available:

• protoc-gen-cpp
• protoc-gen-csharp
• protoc-gen-java
• protoc-gen-kotlin
• protoc-gen-objectivec
• protoc-gen-php
• protoc-gen-python
• protoc-gen-pyi
• protoc-gen-ruby
• protoc-gen-rust

[zhangskz]

Can you mark these all as //visibility:private for now? While we may want to officially support and release standalone binaries for these plugins at some point in the future, we would likely need to add corresponding supporte policies and / or poison pills to ensure protoc and plugin are used with supported version combinations first. Currently defacto with the built-in generators is that protoc + plugins are necessarily at the same version by default.

Keeping these private for now may help a bit with accidental mis-use in the interim, until we can get guardrails in place.

[bufdev]

Unfortunately, making these private would pretty much defeat the goal of this PR - making these usable by others is the whole point :-)

Re: poison pills, do you just mean something like https://github.com/bufbuild/buf/blob/d500877026294fa52819fb20b98101d2c2c70fe3/private/gen/proto/go/buf/alpha/image/v1/image.pb.go#L33 or do you mean something more extensive? If this, we're happy to do this in this PR. If something more extensive, I'd question the need or desire - the rest of the Protobuf plugin ecosystem functions just fine without these type of block FWIW, and I think that's appropriate.

[zhangskz]

Yep, I was referring to some sort of version check enforcing only compatible versions are used!

Discussed with the team and it should be ok to accept these as public targets. Note though that we don't have guarantees for these in our support matrix yet for how these targets would be expected to behave yet esp when versions are mixed, so I do err on preffering some guardrails here (but followup should be fine for that).

[bufdev]

OK great to hear. Other than the failing tests below (which I think are unrelated, I'll merge the latest from main) is there anything else you'd like us to do in this PR?

[zhangskz]

Can you rename these to plugin_main.cc instead of main.cc for consistency?

Looks like we use main.cc for c++ and rust today, and plugin_main.cc for java and python. I think plugin_main.cc is better here, and we should rename c++ and rust to follow that convention as well.

[bufdev]

Done.

[bufdev]

Done! I think you need to re-tag it for tests, but should be good to go otherwise!

[JasonLunn]

@bufdev - Please take a look at the failing tests from the last run.

[bufdev]

@JasonLunn I can only see the current test run, and the reason it is failing is the lack of maintainer approval for the tests to run:

• https://github.com/protocolbuffers/protobuf/actions/runs/25976960367/job/76358671599?pr=23919
• https://github.com/protocolbuffers/protobuf/actions/runs/25976960367/job/76358665798?pr=23919

I can't see other test jobs than those. If there's some other failure, I'm unable to see it as a contributor, let me know.

[JasonLunn]

I see a listing at https://github.com/protocolbuffers/protobuf/actions/runs/25962270977 that includes links to https://github.com/protocolbuffers/protobuf/actions/runs/25962270977/job/76319551490 and https://github.com/protocolbuffers/protobuf/actions/runs/25962270977/job/76319551324 for example

[bufdev]

How did you find that? That's not surfaced to me here or in the Actions view in something I can list. Regardless, I'll look into these failures, thanks.

[bufdev]

Hopefully fixed now? I think it was a bad merge issue. Any chance you can run it again? Apologies for the back and forth.

[JasonLunn]

@bufdev - I’m going to hold off re-labeling in case that’s what obscures the links to the test runs for you

[bufdev]

Phew!