Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better organize Bazel build definitions so that rules_go isn't a hard dependency #48

Open
meteorcloudy opened this issue Jul 6, 2022 · 1 comment

Comments

@meteorcloudy
Copy link

Currently, proto targets for different languages are defined in a BUILD file by loading the xds_proto_package macro (eg. in //xds/data/orca/v3). The bzl file that defines xds_proto_package again loads macros from rules_go:

load("@io_bazel_rules_go//proto:def.bzl", "go_grpc_library", "go_proto_library")

This is a bad practice because it forces any other project (see grpc) which depends on any target in //xds/data/orca/v3 to fetch rules_go, even though the project doesn't depend on the go_proto_library target. This is a common pitfall with Bazel, see bazelbuild/bazel#12835

A better package structure is to split targets into different packages by language, eg

  • proto_library under //xds/data/orca/v3
  • go_proto_library under //xds/data/orca/v3/go
  • py_proto_library under //xds/data/orca/v3/py
  • cc_proto_library under //xds/data/orca/v3/cc

so that dependencies for specific languages are not fetched when the corresponding package is not needed.

To maintain backwards compatibility, you can still have alias targets in //xds/data/orca/v3that points to other language specific packages.

@meteorcloudy
Copy link
Author

FYI @aranguyen @Wyverald

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant