-
-
Notifications
You must be signed in to change notification settings - Fork 286
scalapb_proto_library
is broken when it depends on external targets
#687
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
Comments
didn't bazelbuild/bazel@af36058 fix something related in |
Here's what I think happened: This commit, in addition to adding the correct This change broke Is that accurate @lberki? So yes, @natansil, I think the fix was related to the I've added the same fix to the branch at #685. The proto targets build locally, but I'm still waiting on CI for the full test suite. |
Fix has been merged #685 |
Uh oh!
There was an error while loading. Please reload this page.
I've added a repro of the issue in PR #685. The relevant bits are reproduced below:
test/proto/BUILD
test/proto/test_external_dep.proto
bazel build test/proto:test_external_dep
fails with the following output:I've tracked the issue down to a change in the proto_library providers. For the same repo and build files, the contents of ProtoProvider.proto.transitive_proto_path is different. In 0.19.2, that field is an empty list. In 0.22.0, it contains
external/com_google_protobuf
and.
. The contents of this field is used to populate--proto_path
. This causes the following issues:--proto_path=.
causes the external proto files to be included twice. This causes scalapb to fail, and output no files. When the worker tries to compile 0 files, it fails withMust have input files from either source jars or local files.
--proto_path=external/com_google_protobuf
is incorrect because that directory doesn't exist, and produces the error messageexternal/com_google_protobuf: warning: directory does not exist.
I'm not sure what needs to change here. I'm happy to spend some more time fixing this, but I'm not sure if this is a bug that should be reported to bazel, or if rules_scala needs to be updated.
It looks like this was fixed in the
java_proto_library
rule by simply removingproto_path=.
bazelbuild/bazel@af36058I believe this is related to #312
cc @johnynek
The text was updated successfully, but these errors were encountered: