You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
‘readProtoFiles2’ is different from ‘readProtoFiles’ to be
consistent with the behavior of ‘protoc’ command line tool in
being explicit about the search path for proto import statements.
However, I believe that its behavior is not fully compatible. When I use protoc default search path, including google/protobuf is included. For example if I have a following structure:
.
└── proto
└── foo
└── bar
├── bar.proto
└── foo.proto
google/protobuf/any.proto:0:1:File not found.
foo/bar/foo.proto:5:1:Import "google/protobuf/any.proto" was not found or had errors.
foo/bar/foo.proto:9:3:"google.protobuf.Any" is not defined.
Error: Could not load proto file 'foo/bar/foo.proto'
and I have to explicitly provide path to include dir with google/protobuf/any.proto
I think you have to ask upstream. This project provides the glue to access the protocol buffers library and tools as shipped by Google. We neither set, nor modify, the spec. Of course, if something is different between 'us' and upstream it is likely a bug but methinks you have a pure upstream question here.
That part could be us, and I think we made some very early design choices in the package about where some default path for "default for the package" .proto files are sourced. But as such it is pretty much established behavior and unlikely to change.
So maybe just need to update the documentation and state this.
According to
readProtoFiles2
cos:However, I believe that its behavior is not fully compatible. When I use
protoc
default search path, includinggoogle/protobuf
is included. For example if I have a following structure:with
foo.proto
and
bar.proto
I can
protoc --cpp_out=./gen -I ./proto proto/foo/bar/*
In contrast, if I use the following:
I get
and I have to explicitly provide path to
include
dir withgoogle/protobuf/any.proto
to make things work.
Is it the intended behavior?
The text was updated successfully, but these errors were encountered: