Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add proto_common.direct_source_infos #22
Add proto_common.direct_source_infos #22
Changes from all commits
2fdaa50
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why isn't this a member of
ProtoInfo
? Sounds like a reasonable functionality there. (I might be missing something obvious here, since I haven't been following this pull request very closely)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about making import paths of direct sources part of
ProtoInfo
before but never came to a conclusion.ProtoInfo
already is "complicated" (:cough: original sources) and I'd like to avoid adding more half-baked stuff to it. Can you file a feature request?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoa, I think I caught an actual bug. This logic seems to want to do same thing as the the exec path -> import path logic from the Java code:
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/proto/ProtoCompileActionBuilder.java#L633
but it doesn't do that, AFAIU: it diverges for
.proto
files in external repositories and generated.proto
files (yes, they do exist)Do I understand this correctly? If so, it might be more reasonable to expose this information from Java in the interest of not re-implementing the same functionality twice. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the case in which it doesn't work.
We do have coverage for external repositories, so I'm confident that works correctly. We don't have tests for generated
.proto
files here, but aren't they always simlink'ed into<pkg>/_virtual_imports/<name>/<import_path>
since bazelbuild/bazel#9215, thus work as well?The only case I see when this logic could fail is when the file is not under
proto_source_root
(which, AFAIK, cannot happen since Bazel 1.0). What am I missing?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're totally right! However, there is also the problem of the direct proto source root being a lie (e.g. if a
proto_library
has both source and derived.proto
files, not all of them are going to be under.proto_source_root
.I suppose bazelbuild/bazel#10939 will help with that?