The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) https://grpc.io/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

106 lines
4.2 KiB

"""Generates and compiles C++ grpc stubs from proto_library rules."""
load("@rules_proto//proto:defs.bzl", "proto_library")
load("//bazel:generate_cc.bzl", "generate_cc")
load("//bazel:protobuf.bzl", "well_known_proto_libs")
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
def cc_grpc_library(
name,
srcs,
deps,
proto_only = False,
well_known_protos = False,
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
generate_mocks = False,
use_external = False,
grpc_only = False,
**kwargs):
"""Generates C++ grpc classes for services defined in a proto file.
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
If grpc_only is True, this rule is compatible with proto_library and
cc_proto_library native rules such that it expects proto_library target
as srcs argument and generates only grpc library classes, expecting
protobuf messages classes library (cc_proto_library target) to be passed in
deps argument. By default grpc_only is False which makes this rule to behave
in a backwards-compatible mode (trying to generate both proto and grpc
classes).
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
Assumes the generated classes will be used in cc_api_version = 2.
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
Args:
name (str): Name of rule.
srcs (list): A single .proto file which contains services definitions,
or if grpc_only parameter is True, a single proto_library which
contains services descriptors.
deps (list): A list of C++ proto_library (or cc_proto_library) which
provides the compiled code of any message that the services depend on.
proto_only (bool): If True, create only C++ proto classes library,
avoid creating C++ grpc classes library (expect it in deps).
Deprecated, use native cc_proto_library instead. False by default.
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
well_known_protos (bool): Should this library additionally depend on
well known protos. Deprecated, the well known protos should be
specified as explicit dependencies of the proto_library target
(passed in srcs parameter) instead. False by default.
generate_mocks (bool): when True, Google Mock code for client stub is
generated. False by default.
use_external (bool): Not used.
grpc_only (bool): if True, generate only grpc library, expecting
protobuf messages library (cc_proto_library target) to be passed as
deps. False by default (will become True by default eventually).
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
**kwargs: rest of arguments, e.g., compatible_with and visibility
"""
if len(srcs) > 1:
fail("Only one srcs value supported", "srcs")
if grpc_only and proto_only:
fail("A mutualy exclusive configuration is specified: grpc_only = True and proto_only = True")
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
extra_deps = []
proto_targets = []
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
if not grpc_only:
proto_target = "_" + name + "_only"
cc_proto_target = name if proto_only else "_" + name + "_cc_proto"
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
proto_deps = ["_" + dep + "_only" for dep in deps if dep.find(":") == -1]
proto_deps += [dep.split(":")[0] + ":" + "_" + dep.split(":")[1] + "_only" for dep in deps if dep.find(":") != -1]
if well_known_protos:
proto_deps += well_known_proto_libs()
proto_library(
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
name = proto_target,
srcs = srcs,
deps = proto_deps,
**kwargs
)
native.cc_proto_library(
name = cc_proto_target,
deps = [":" + proto_target],
**kwargs
)
extra_deps.append(":" + cc_proto_target)
proto_targets.append(proto_target)
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
else:
if not srcs:
fail("srcs cannot be empty", "srcs")
proto_targets += srcs
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
if not proto_only:
codegen_grpc_target = "_" + name + "_grpc_codegen"
generate_cc(
name = codegen_grpc_target,
srcs = proto_targets,
plugin = "@com_github_grpc_grpc//src/compiler:grpc_cpp_plugin",
Make cc_grpc_library compatible with native proto_library and cc_proto_library rules. This is needed to comply with bazel best practices (each proto file is first processed by proto_library: https://docs.bazel.build/versions/master/be/protocol-buffer.html#proto_library) and generally bring cc_grcp_library rule up to date with latest Bazel changes (the rule hasn't gotten much updates since 2016). Detailed description. Bazel has native `cc_proto_library` rule, but it does not have `cc_grpc_library`. The rule in cc_grpc_library in this repo seems like the best candidate. This change makes possible using `cc_grpc_library` to generate on grpc library, and consume protobuf protion as dependencies. The typical `BUILD.bazel` file configuraiton now should look like the following: ```python proto_library( name = "my_proto", srcs = ["my.proto"], ) cc_proto_library( name = "my_cc_proto", deps = [":my_proto"] ) cc_grpc_library( name = "my_cc_grpc", srcs = [":my_proto"], deps = [":my_cc_proto"] ) ``` This allows to decouple all thre phases: proto descriptors generation (`proto_library`), protobuf messages library creation (`cc_proto_library`), grpc library creatio (`cc_grpc_library`). Notice how `cc_grpc_library` depends on `proto_library` (as `src`) and on `cc_proto_library` (as `deps`). Currently cc_grpc_library is designed in a way that it encapsulates all of the above and directly accepts .proto files as srcs. The previous version (before this PR) of cc_proto_library was encapsulating all of the 3 phases inside single `cc_proto_library` and also was doing it manually (without relying on the native `cc_proto_library`). The `cc_proto_library` is kept backward-compatible with the old version.
6 years ago
well_known_protos = well_known_protos,
generate_mocks = generate_mocks,
**kwargs
)
native.cc_library(
name = name,
srcs = [":" + codegen_grpc_target],
hdrs = [":" + codegen_grpc_target],
deps = deps +
extra_deps +
["@com_github_grpc_grpc//:grpc++_codegen_proto"],
**kwargs
)