1# This BUILD file shows how to use protobuf with bazel. Before you can use 2# proto_library/<lang>_proto_library rules in a BUILD file, you need to 3# include protobuf repo as remote repositories in your WORKSPACE file. See 4# the WORKSPACE file in the same directory with this BUILD file for an 5# example. 6 7load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_proto_library") 8load("@rules_java//java:defs.bzl", "java_binary", "java_lite_proto_library", "java_proto_library") 9load("@rules_proto//proto:defs.bzl", "proto_library") 10 11# For each .proto file, a proto_library target should be defined. This target 12# is not bound to any particular language. Instead, it defines the dependency 13# graph of the .proto files (i.e., proto imports) and serves as the provider 14# of .proto source files to the protocol compiler. 15# 16# Remote repository "com_google_protobuf" must be defined to use this rule. 17proto_library( 18 name = "addressbook_proto", 19 srcs = ["addressbook.proto"], 20 deps = ["@com_google_protobuf//:timestamp_proto"], 21) 22 23# The cc_proto_library rule generates C++ code for a proto_library rule. It 24# must have exactly one proto_library dependency. If you want to use multiple 25# proto_library targets, create a separate cc_proto_library target for each 26# of them. 27# 28# Remote repository "com_google_protobuf_cc" must be defined to use this rule. 29cc_proto_library( 30 name = "addressbook_cc_proto", 31 deps = [":addressbook_proto"], 32) 33 34# cc_library/cc_binary targets can depend on cc_proto_library targets. 35cc_binary( 36 name = "add_person_cpp", 37 srcs = ["add_person.cc"], 38 deps = [":addressbook_cc_proto"], 39) 40 41cc_binary( 42 name = "list_people_cpp", 43 srcs = ["list_people.cc"], 44 deps = [":addressbook_cc_proto"], 45) 46 47# Similar to cc_proto_library but for Java. 48# 49# Remote repository "com_google_protobuf_java" must be defined to use this rule. 50java_proto_library( 51 name = "addressbook_java_proto", 52 deps = [":addressbook_proto"], 53) 54 55java_binary( 56 name = "add_person_java", 57 srcs = ["AddPerson.java"], 58 main_class = "AddPerson", 59 deps = [":addressbook_java_proto"], 60) 61 62java_binary( 63 name = "list_people_java", 64 srcs = ["ListPeople.java"], 65 main_class = "ListPeople", 66 deps = [":addressbook_java_proto"], 67) 68 69# Java lite. 70# 71# Remote repository "com_google_protobuf_javalite" must be defined to use this 72# rule. 73java_lite_proto_library( 74 name = "addressbook_java_lite_proto", 75 deps = [":addressbook_proto"], 76) 77 78# Java lite API is a subset of the regular Java API so if you only uses this 79# subset in your code, you can actually compile your code against both (i.e., 80# share code between server build and Android build). 81# 82# The lite version has a smaller code size, and you can see that by comparing 83# the resulted .jar file: 84# 85# $ bazel build :add_person_java_deploy.jar :add_person_java_lite_deploy.jar 86# $ ls -l bazel-bin/*_deploy.jar 87# -r-xr-xr-x 1 xiaofeng eng 1230797 Sep 8 12:24 bazel-bin/add_person_java_deploy.jar 88# -r-xr-xr-x 1 xiaofeng eng 236166 Sep 8 12:24 bazel-bin/add_person_java_lite_deploy.jar 89# 90# In the above example, the lite .jar file is 6 times smaller. With proper 91# proguard inlining/stripping, the difference can be much more larger than 92# that. 93java_binary( 94 name = "add_person_java_lite", 95 srcs = ["AddPerson.java"], 96 main_class = "AddPerson", 97 deps = [":addressbook_java_lite_proto"], 98) 99 100java_binary( 101 name = "list_people_java_lite", 102 srcs = ["ListPeople.java"], 103 main_class = "ListPeople", 104 deps = [":addressbook_java_lite_proto"], 105) 106