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

Allow runtime_deps to be specified for kt_jvm_proto_library #505

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alexenvoy
Copy link

A common use case we run into is producing the Kotlin proto library for a proto file A that depends on one or more proto files B. In such a case we would like to produce the Kotlin proto library for both A and B so we can use the Kotlin DSL to build both A and its nested fields of type B. However, the kt_jvm_proto_library macro does not have a way to express this quasi-dependency relationship. For example we have:

proto_library(
    name = "a_proto",
    srcs = ["a.proto"],
    deps = [":b_proto"],
)

proto_library(
    name = "b_proto",
    srcs = ["b.proto"],
)

kt_jvm_proto_library(
    name = "a_kt_proto",
    deps = [":a_proto"],
)

kt_jvm_proto_library(
    name = "b_kt_proto",
    deps = [":b_proto"],
)

We're not able to have users of the a_kt_proto target to automatically pull in b_kt_proto. We can work around this by addingb_proto directly as a dep of a_kt_proto so that both are compiled together. But this is less than ideal because, we may also have a c_proto that also depend on b_proto. If we put b_proto as a direct dependency of both a_kt_proto and c_kt_proto, the same file is compiled twice, and later on when we assemble a Jar combining a_kt_proto and c_kt_proto we get a conflict.

Of course a_kt_proto does not really depend on b_kt_proto, so everything still compiles and works. But users would expect to be able to use the Kotlin DSL to build all parts of the a.proto messages, including the parts that are from b.proto. And we do not want users to go hunt for all transitive dependencies of a.proto to find the corresponding kt_jvm_proto_library targets and assemble the dependency graph themselves. I think the runtime_deps concept appropriately captures the relationship between the two kt_jvm_proto_library targets, and we can accomplish the transitive dependency pulling by simply adding b_kt_proto as a runtime_dep of a_kt_proto. This PR adds rumtime_deps to the kt_jvm_proto_library to support this use case

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

Successfully merging this pull request may close these issues.

None yet

1 participant