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

Circular dependency in generated proto_library rules #45

Closed
ashi009 opened this issue Dec 20, 2017 · 0 comments
Closed

Circular dependency in generated proto_library rules #45

ashi009 opened this issue Dec 20, 2017 · 0 comments

Comments

@ashi009
Copy link
Contributor

ashi009 commented Dec 20, 2017

In case a package contains multiple proto files:

  • these files have the same go_package option, and
  • some of these files are importing some others (no circular dependency)

gazelle will put them in the same proto_library rule with a dependency to itself. The generated go_proto_library will have the same issue.

Take google/api/{http,annotations}.proto for instance. They both have option go_package = "google.golang.org/genproto/googleapis/api/annotations;annotations", and annotations.proto imports http.proto. gazelle will generate the follow code:

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

proto_library(
    name = "annotations_proto",
    srcs = [
        "annotations.proto",
        "http.proto",
    ],
    visibility = ["//visibility:public"],
    deps = [
        ":annotations_proto",      <---------- CIRCULAR DEPENDENCY
        "@com_google_protobuf//:descriptor_proto",
    ],
)

go_proto_library(
    name = "annotations_go_proto",
    importpath = "google/api",
    proto = ":annotations_proto",
    visibility = ["//visibility:public"],
    deps = [
        ":go_default_library",      <---------- CIRCULAR DEPENDENCY
        "@com_github_golang_protobuf//protoc-gen-go/descriptor:go_default_library",
    ],
)
jayconrod pushed a commit to jayconrod/bazel-gazelle that referenced this issue Dec 26, 2017
Add selfImportError, which is now returned by
RuleIndex.findRuleByImport and related methods when a rule imports
itself (which is common with protos).

Resolver methods treat this error the same as standardImportError: no
dependency is emitted.

Fixes bazelbuild#45
jayconrod added a commit that referenced this issue Dec 27, 2017
Add selfImportError, which is now returned by
RuleIndex.findRuleByImport and related methods when a rule imports
itself (which is common with protos).

Resolver methods treat this error the same as standardImportError: no
dependency is emitted.

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

No branches or pull requests

2 participants