Implicit dependencies generated by cpp_grpc_library

[sfc-gh-sgiesecke]

Description

The cpp_grpc_library rule currently generates dependencies on grpc++ and grpc++_reflection (which depends on grpc++ again). This is a problem in some of our uses where we eventually want to link against grpc++_unsecure.

I wonder if it were sufficient to just depend on grpc++_public_hdrs here, and thus make this agnostic to what variant of grpc++/grpc++_unsecure will eventually be linked.

The alternative would be to provide an "unsecure" variant (or a parameter) of the rule. But that might lead into conflicts if a dependent ends up depending on both "secure" and "unsecure" cpp_grpc_library instances, also it doesn't feel like a property of the service definition as such whether it will be used in a "secure" or "unsecure" context.

[aaliddell]

We can't remove the link to an implementation and just link to the headers only, as we would break backwards compatibility on all existing users who would then see link failures. Given that grpc++ is a superset of the features of grpc++_unsecure, what's the use case for linking grpc++_unsecure? Is it binary size or avoiding a dependency on a TLS library?

Anyway, the cpp_*_library rules are provided as a generic 'common denominator' design to link a language library in the way that satisfies the requirements of most users and are quick to get started with; for use cases that it doesn't capture (such as custom linkage), then the usual suggestion is you instead use cpp_*_compile to just get the raw files from protoc and then bundle them into a cc_library manually. You can even copy the existing cpp_*_library as a template for the baseline implementation of such an override and change GRPC_DEPS (or replace with grpc++_public_hdrs to then delegate specific implementation linking to your cc_binary).

For now I will close this, as the above is the closest to an 'official' solution to custom linkage. If there's wider demand please voice it here and I'll look into adding a flag to `cpp_grpc_library'

[sfc-gh-sgiesecke]

We can't remove the link to an implementation and just link to the headers only, as we would break backwards compatibility on all existing users who would then see link failures.

Well yes, it would be a breaking change.

what's the use case for linking grpc++_unsecure? Is it binary size or avoiding a dependency on a TLS library?

The immediate use case is the latter.

It might also be the former in other contexts.

Anyway, the cpp_*_library rules are provided as a generic 'common denominator' design to link a language library in the way that satisfies the requirements of most users and are quick to get started with

Hm, that's a bit disappointing. This doesn't seem too healthy for the Bazel ecosystem, as one would hope for a canonical solution. While in the case at hand, we indeed have the BUILD.bazel file that defines the cpp_grpc_library under control, and can replace it by something else, it might well be that one wants to consume another dependency that defines a cpp_grpc_library that needs to be linked with grpc++_unsecure instead.

[sfc-gh-ebrossard]

We ended up working around this by patching cpp_grpc_library locally only to depend on @com_github_grpc_grpc//:grpc++_public_hdrs. What was somewhat complicated, though, is that gRPC doesn't have a headers-only target for the reflection headers, so we also had to patch gRPC to provide those as well. It seems like the right long-term fix is probably to have gRPC avoid compiling the same source files as part of the grpc++ and grpc++_unsecure targets, though, and then rules_proto_grpc could just depend on whatever minimal dependencies it needs (presumably a parent of the two), but that seems like a much larger undertaking.