As far as I know, the direct deps should be sufficient for parsing .proto
files and generating descriptors from them. The one thing I'm not sure
about is parsing of custom options; I don't know if we allow proto files to
set custom options and reference fields that aren't in the direct deps.
For
It is strongly recommended that proto rules use aspects going forward,
because it avoids the need to specify the dependency graph N times (one per
language). proto_library() can specify the dependency graph once, and then
any number of languages can have lang_proto_library() rules that reuse
Thanks Adam, do you have a sense of whether it should be possible
fundamentally? i.e. is there any data in a FileDescriptor that can't be
populated unless you have both direct and indirect deps available? If not,
I might take a poke at adding a protoc flag to set that option, and see if
I can
Thanks Josh! I will have a look at proto_common and see what I can glean
from it.
More generally, is there any guidance around how/whether proto codegen
rules should use aspects? My current rule implementation does not use
aspects at all if I'm understanding correctly - I'm just forming
Getting protoc to work with only direct dependencies is an interesting idea
because it has the potential to meaningfully speed up builds, but as Josh
said, protoc is not currently set up to be able to do that.
I think the way to do this would be to start by calling
AllowUnknownDependencies
Hi Brandon,
The proto compiler doesn't generally allow what you are asking for. It
always wants to see the full closure of .proto files.
But if you are writing for Bazel, you shouldn't have to worry about any of
that. As long as you are on Bazel >=5.3, you can use proto_common to handle
most
