@@ -144,6 +144,78 @@ protobuf_repositories(
144144)
145145```
146146
147+
148+ # Imports
149+
150+ In all cases, these rules will include a ` --proto_path=. ` argument.
151+ This is functionally equivalent to `--proto_path=$(bazel info
152+ execution_root)`. Therefore, when the protoc tool is invoked, it will
153+ 'see' whatever directory struture exists at the bazel execution root
154+ for your workspace. To better learn what this looks like, `cd $(bazel
155+ info execution_root)` and look around. In general, it contains all
156+ your sourcefiles as they appear in your workspace, with an additional
157+ ` external/WORKSPACE_NAME ` directory for all dependencies used.
158+
159+ This has implications for import statements in your protobuf
160+ sourcefiles, if you use them. The two cases to consider are imports
161+ * within* your workspace (referred to here as 'internal' imports), and
162+ imports of other protobuf files in an external workspace.
163+
164+ ### Internal Imports
165+
166+ Internal imports should require no additional parameters if your
167+ import statements follow the directory structure of your workspace.
168+ For example, the ` examples/helloworld/proto/helloworld.proto ` file
169+ imports the ` examples/proto/common.proto ` file. Since this follows
170+ the same directory structure as the workspace, ` protoc ` can find it,
171+ and no additional arguments to a ` cc_proto_library ` are required for
172+ protoc tool.
173+
174+ * However* , the ` cc_proto_library ` rule in
175+ ` examples/helloworld/proto/BUILD:cpp ` names the
176+ ` //examples/proto:cpp ` 's ` cc_proto_library ` rule as a dependency in
177+ order to (1) trigger generation of the ` common.pb.{h,cc} ` files AND
178+ (2) include those generated files in the ` cc_library ` rule for
179+ compiling the object files.
180+
181+ Additional ` --proto_path ` (` -I ` ) arguments can be supplied via the
182+ ` imports = [] ` attribute common to all rules.
183+
184+ ### External Imports
185+
186+ The same logic applied to external imports. The two questions to answer are
187+
188+ 1 . * Can protoc "see" the imported file?* In order to satisfy this
189+ requirement, pass in the full path of the required file relative to
190+ your execution root. For example, the the well-known descriptor
191+ proto could be made visible to protoc via something like...
192+
193+ ``` python
194+ java_proto_library(
195+ name = ' fooprotos' ,
196+ srcs = ' foo.proto`,
197+ imports = [
198+ " external/com_github_google_protobuf/src/" ,
199+ ],
200+ )
201+ ```
202+
203+ ...given that the file
204+ ` @com_github_google_protobuf/src/google/protobuf/descriptor.proto ` is
205+ in the package ` google.protobuf ` .
206+
207+ 2 . * Can the ` {LANG}_proto_library ` rule "see" the generated protobuf
208+ files (in this case ` descripttor.pb.{h,cc} ` . Just because the file
209+ was imported does not imply that protoc will generate outputs for
210+ it, so somewhere in the ` cc_library ` rule dependency chain these
211+ files must be present. This could be via another
212+ ` cc_proto_library ` rule defined elswhere, or a some other filegroup
213+ or label list. If the source is another ` cc_proto_library ` rule,
214+ specify that in the ` deps ` attribute to the calling
215+ ` cc_proto_library ` rule. Otherwise, pass it to the ` cc_srcs ` or
216+ perhaps ` cc_deps ` attribute to the calling ` cc_proto_library ` rule.
217+ Hopefully that made sense. It's tricky.
218+
147219# Contributing
148220
149221Contributions welcome; please create Issues or GitHub pull requests.
0 commit comments