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.

248 lines
5.5 KiB

# Copyright 2017 gRPC authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
licenses(["notice"]) # 3-clause BSD
package(default_visibility = ["//visibility:public"])
load("@grpc_python_dependencies//:requirements.bzl", "requirement")
load("@rules_proto//proto:defs.bzl", "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
load("//bazel:cc_grpc_library.bzl", "cc_grpc_library")
load("//bazel:grpc_build_system.bzl", "grpc_proto_library")
load("//bazel:python_rules.bzl", "py_grpc_library", "py_proto_library")
grpc_proto_library(
name = "auth_sample",
srcs = ["protos/auth_sample.proto"],
)
grpc_proto_library(
name = "hellostreamingworld",
srcs = ["protos/hellostreamingworld.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
# The following three rules demonstrate the usage of the cc_grpc_library rule in
# in a mode compatible with the native proto_library and cc_proto_library rules.
proto_library(
name = "helloworld_proto",
srcs = ["protos/helloworld.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
cc_proto_library(
name = "helloworld_cc_proto",
deps = [":helloworld_proto"],
)
cc_grpc_library(
name = "helloworld_cc_grpc",
srcs = [":helloworld_proto"],
grpc_only = True,
deps = [":helloworld_cc_proto"],
)
grpc_proto_library(
name = "route_guide",
srcs = ["protos/route_guide.proto"],
)
grpc_proto_library(
name = "keyvaluestore",
srcs = ["protos/keyvaluestore.proto"],
)
proto_library(
name = "protos/helloworld_proto",
srcs = ["protos/helloworld.proto"],
)
py_proto_library(
name = "helloworld_py_pb2",
5 years ago
deps = [":protos/helloworld_proto"],
)
py_grpc_library(
name = "helloworld_py_pb2_grpc",
srcs = [":protos/helloworld_proto"],
deps = [":helloworld_py_pb2"],
)
cc_binary(
name = "greeter_client",
srcs = ["cpp/helloworld/greeter_client.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
cc_binary(
name = "greeter_async_client",
srcs = ["cpp/helloworld/greeter_async_client.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
cc_binary(
name = "greeter_async_client2",
srcs = ["cpp/helloworld/greeter_async_client2.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
cc_binary(
name = "greeter_server",
srcs = ["cpp/helloworld/greeter_server.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
"//:grpc++_reflection",
],
)
cc_binary(
name = "greeter_async_server",
srcs = ["cpp/helloworld/greeter_async_server.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
6 years ago
cc_binary(
name = "metadata_client",
srcs = ["cpp/metadata/greeter_client.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
cc_binary(
name = "metadata_server",
srcs = ["cpp/metadata/greeter_server.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
6 years ago
cc_binary(
name = "lb_client",
srcs = ["cpp/load_balancing/greeter_client.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
6 years ago
)
cc_binary(
name = "lb_server",
srcs = ["cpp/load_balancing/greeter_server.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
6 years ago
)
cc_binary(
name = "compression_client",
srcs = ["cpp/compression/greeter_client.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
cc_binary(
name = "compression_server",
srcs = ["cpp/compression/greeter_server.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":helloworld_cc_grpc",
"//:grpc++",
],
)
cc_binary(
name = "keyvaluestore_client",
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
srcs = [
"cpp/keyvaluestore/caching_interceptor.h",
"cpp/keyvaluestore/client.cc",
],
defines = ["BAZEL_BUILD"],
deps = [
":keyvaluestore",
"//:grpc++",
],
)
cc_binary(
name = "keyvaluestore_server",
srcs = ["cpp/keyvaluestore/server.cc"],
defines = ["BAZEL_BUILD"],
deps = [
":keyvaluestore",
"//:grpc++",
],
)
cc_binary(
name = "route_guide_client",
srcs = [
"cpp/route_guide/helper.cc",
"cpp/route_guide/helper.h",
"cpp/route_guide/route_guide_client.cc",
],
data = ["cpp/route_guide/route_guide_db.json"],
defines = ["BAZEL_BUILD"],
deps = [
":route_guide",
"//:grpc++",
],
)
cc_binary(
name = "route_guide_server",
srcs = [
"cpp/route_guide/helper.cc",
"cpp/route_guide/helper.h",
"cpp/route_guide/route_guide_server.cc",
],
data = ["cpp/route_guide/route_guide_db.json"],
defines = ["BAZEL_BUILD"],
deps = [
":route_guide",
"//:grpc++",
],
)
proto_library(
name = "route_guide_proto",
srcs = ["protos/route_guide.proto"],
)