[FR]: Add example for `cc_proto_library`

[malt3]

What is the current behavior?

I can't quite get cc_proto_library to work and there is no end-to-end example for C++.

Describe the feature

I'd like to enable --incompatible_enable_proto_toolchain_resolution and use a precompiled protoc.
I got this mostly working:

MODULE.bazel:

bazel_dep(name = "rules_proto", version = "6.0.2")
bazel_dep(name = "toolchains_protoc", version = "0.3.1")

protoc = use_extension("@toolchains_protoc//protoc:extensions.bzl", "protoc")
protoc.toolchain(
    # Creates a repository to satisfy well-known-types dependencies such as
    # deps=["@com_google_protobuf//:any_proto"]
    google_protobuf = "com_google_protobuf",
    version = "LATEST",
)

use_repo(protoc, "com_google_protobuf", "toolchains_protoc_hub", "toolchains_protoc_hub.linux_x86_64")

register_toolchains("@toolchains_protoc_hub//:all")
register_toolchains("//toolchain:protoc_cc_toolchain")

toolchain/BUILD:

load("@rules_proto//proto:defs.bzl", "proto_lang_toolchain")

proto_lang_toolchain(
    name = "protoc_cc",
    runtime = "@toolchains_protoc_hub.linux_x86_64//:prebuilt_protoc_toolchain",
    command_line = "--cpp_out=$(OUT)",
    progress_message = "Generating C++ proto_library %{label}",
    toolchain_type = "@rules_cc//cc/proto:toolchain_type",
)

BUILD:

load("@rules_proto//proto:defs.bzl", "proto_library")

cc_proto_library(
    name = "foo_cc_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
    srcs = ["foo.proto"],
    features = ["-asan"],
)

foo.proto:

syntax = "proto3";

package foo;

message Bar {
    uint64 baz = 1;
}

Output:

fatal error: google/protobuf/runtime_version.h: No such file or directory

edit

I think the runtime attribute of proto_lang_toolchain should be something like @com_google_protobuf//:protoc_lib.
I’ll experiment some more.

[alexeagle]

In theory, C++ doesn't have to be covered here because the official Protobuf documentation says that C++ developers ought to build it from source:
https://github.com/protocolbuffers/protobuf#protobuf-compiler-installation

If you author C++ code then it's reasonable to require every engineer on your team has a functioning local toolchain, or you've configured Bazel with a hermetic toolchain.

In practice of course it's ALWAYS annoying to compile protoc and watch its gcc warnings scrolling by, and I'd love to have C++ here too!

[alexeagle]

Tagging @thesayyn who might recall whether any work happened with cc_proto_library to make this possible

[ouillie]

Just to add a bit of context, it's entirely possible that you don't author any C++ code, but still need a C++ toolchain. In my case, the Python gRPC plugin is implemented in C++ and needs to generate C++ libraries for CodeGeneratorRequest etc., so Python proto libraries compile quickly, but Python gRPC libraries do not.

[alexeagle]

@ouillie I had exactly that discussion with a team today, who wishes the scope of this repo included gRPC as well to avoid building those programs from source. Sadly that scope increase isn't funded here.

[ouillie]

Ah. Well, I just forked gRPC and added a little script to upload pre-built plugin binaries for Linux / MacOS e.g. v1.67.1. It's a pretty small/easy script. I'll see if they're OK with taking it upstream.

Would you have any appetite for me to submit a PR to toolchains_protoc to make use of them? Otherwise, it wouldn't be too hard for that team to make use of them anyway with an http_archive and manually setting up the toolchain with a plugin.

[chrisirhc]

Just thinking aloud, the Python gRPC plugin is also published as grpcio-tools, could this py_binary be used as a executable tool for the grpc plugin?

Update: Yes, seems like it can be used, see https://github.com/chrisirhc/precompiled-grpc-in-bazel-python . However, you'll be coupling your grpc version with the protoc plugin version brought in by the grpcio-tools.

Blog post: https://blog.sirh.cc/post/precompiled-grpc-compiler-bazel-python/

[alexeagle]

I tried this out today (now that this repo has a more precise way to avoid compiling protoc rather than just breaking the whole cc toolchain).

I find that it's blocked on protocolbuffers/protobuf#19679 landing, as the cc_proto_library rule is hard-coded to point to the cc_binary target rather than consult the Bazel toolchain.