Can we remove ProtoInfo dependency from cc_shared_library?

[dzbarsky]

See discussion in https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1769609519112949

Following some of the context, it sounds like perhaps the ProtoInfo is not necessary and can be removed? Removing it would allow removing protobuf dependency completely from rules_cc.

If we need it to reduce propagation, perhaps rules_cc can define a marker provider that proto_library rule can implement, so the module dependency edge goes only one way?

cc @trybka @fmeum @oquenchil @armandomontanez

[keith]

see also #492

[armandomontanez]

Reiterating from the Slack: I'd like to spin up a test for this. I suspect ProtoInfo was added along the way as a guess for fixing the problem, and didn't end up being necessary after the rest of the patch was built out.

[trybka]

some notes from @oquenchil :

a linker_input has an owner which is essentially the label of the target that created that linker_input
a linker_input created by a cc_proto_library doesn't have its own label, it takes the label from the original proto target, i.e. aspects don't have their own labels
What cc_shared_library does is [not ideal] but ... I don't currently know of a better solution. But basically it reconstructs the whole graph with an aspect which returns the labels of each node in the graph. It's only interested in C++ nodes though. A proto target might be a C++ node

[fmeum]

Couldn't this be solved by adding CcInfo to required_aspect_providers? That seems more correct as well since it would apply to any code generating aspect.

[trybka]

Just to make sure stuff mentioned offline is on this bug:

Couldn't this be solved by adding CcInfo to required_aspect_providers?

it's already in the graph_structure_aspect

I think it has to do with cc_proto_library not being the right owning label? (that was what I think I got from @oquenchil 's comment)

[dzbarsky]

I'm not sure how the owning label is used but does that mean this rule does not work correctly for other aspect-based IDL code generators? (Thrift, flatbuffers, etc). I guess I don't understand why proto is special and needs to be hardcoded in the rules (other than prevalence at Google)

[trybka]

I don't know if those work or not. I think an alternate proposal might be to add the CcSharedLibraryHintInfo to proto_library (which if the other aspect-based IDLs don't already do could allow them to work as well).

But I think we need a test case to try this on.

[pcjanzen]

A related problem is that the protobuf runtime libraries are provided via a toolchain, not a dep, so the aspect never sees them.

[alexeagle]

@pcjanzen the aspect just needs to declare that it requires the toolchain, like https://github.com/bazel-contrib/rules_ruby/blob/main/ruby/private/proto.bzl#L63-L69

[pcjanzen]

The point of this issue is that we want to remove the dependency of rules_cc upon protobuf, so if we were to add the protobuf toolchain to the graph_structure_aspect and teach it about the internal structure of its toolchain, that's going in the exact wrong direction.

[alexeagle]

I think you want to be able to reference the providers and toolchain_type's from proto without having the gross overdependencies of protobuf/MODULE.bazel? IMO we should publish rules_proto again, with only the interop symbols, as a good common zero-dep root dependency so we can all interop our rulesets.
Currently it sounds like we are driving the ecosystem in two opposite directions, and maybe will make the problem worse.

work correctly for other aspect-based IDL code generators? (Thrift, flatbuffers, etc)

💯 to this @dzbarsky - with a small amount of effort we could make one of those work very nicely across the whole Bazel ecosystem by being principled about stability and layering.