Include the path to the repository containing .proto files in the path passed under --proto_path=.

Previously, we used a haphazard algorithm to determine the --direct_dependencies, --allowed_public_imports and -I arguments that worked as follows for a given .proto file:

- For each direct source root, determine if the .proto file lies under that source root
- If so, add the path of the .proto file relative to that source root to the command line
- Add the repository-relative path of the .proto file for good measure

we also omitted the repository "external/<REPO>" prefixes from --proto_path arguments. This resulted in:

1. .proto files in external repositories not working
2. We allowed some imports that we should not have. In particular:
  * When a proto_source_root was the subdirectory of another one, .proto files under the "inner" source root were accessible through the outer one (e.g. if "a" and "a/b" were source roots, "a/b/c.proto" would be accessible as b/c.proto and as c.proto even if the rule contributing the "a" source root did not declare it as an input)
  * When all proto_library rules in a compilation declared a source root, .proto files would still be accessible at their exec paths (e.g. if "a/b.proto" was contributed by a proto_library that set the source root to "a", "import a/b.proto" would still be valid.

To fix the first problem, we now properly prefix --proto_path= arguments with repository prefixes This way, for example, proto_library rule @a//b:c will pass external/a/b (or external/a, if proto_source_root is not set on the rule) to --proto_path for all protoc invocations of proto_library rules that transitively depend on it.

This is by no means perfect because we still rely on guesswork to match proto source roots to .proto files and we need to add the exec path so that we don't break existing uses and thus the above illegal imports are still allowed, but we are at a better place than before.

Unfortunately, fixing this properly would require changing ProtoSourcesProvider to maintain the proto source root for each .proto file, which would be an incompatible Starlark change.

Fixes #4665.

RELNOTES: None.
PiperOrigin-RevId: 222596330
6 files changed
tree: 6afc42c3b52f5fdb0d696942f618ad605710159a
  1. .bazelci/
  2. examples/
  3. scripts/
  4. site/
  5. src/
  6. third_party/
  7. tools/
  8. .gitattributes
  9. .gitignore
  10. AUTHORS
  11. BUILD
  12. CHANGELOG.md
  13. CODEOWNERS
  14. combine_distfiles.py
  15. combine_distfiles_to_tar.sh
  16. compile.sh
  17. CONTRIBUTING.md
  18. CONTRIBUTORS
  19. distdir.bzl
  20. ISSUE_TEMPLATE.md
  21. LICENSE
  22. README.md
  23. WORKSPACE
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel only rebuilds what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Contributing to Bazel

See CONTRIBUTING.md

Build status

Bazel is released in ‘Beta’. See the product roadmap to learn about the path toward a stable 1.0 release.