Hi, I have a similar query, If im using a thirdparty proto file for server implementation, how can I generate grpc.pb.cc/pb.cc required for all related protos as well.Like envoy frontproxy control plane grpc protos, I want to implement only Endpoint Discovery Service. Doing proto generation for all available proto files in control_plane directory is the only way to go ahead?Please guide.
Thanks and regards, A Sooryaa On Saturday, April 13, 2013 at 12:03:23 AM UTC+5:30, Feng Xiao wrote: > > > > > On Fri, Apr 12, 2013 at 9:14 AM, Leonid G <[email protected] > <javascript:>> wrote: > >> >> Hi, >> >> I have 2 proto files: imported.proto and importing.proto. >> >> imported.proto: >> package first; >> message first_msg { optional bool fld = 1; } >> >> importing.proto: >> package second; >> import "test/imported.proto" ; >> message second_msg { optional first.first_msg field1 = 1; } >> >> I have place both files into "test" directory and when invoking protoc >> like this: >> protoc --cpp_out=test -I ./test -I . test/importing.proto >> test/imported.proto >> > You should invoke protoc using the following command: > protoc --cpp_out=. test/importing.proto test/imported.proto > Then compile the generated code like this: > g++ -I. -c test/importing.pb.cc test/imported.pb.cc > > > >> >> I getting errors: >> imported.proto:3:30: "first_msg.fld" is already defined in file >> "test/imported.proto". >> imported.proto:1:9: "first_msg" is already defined in file >> "test/imported.proto". >> >> Which indicates to me that when protoc processes test/importing.proto it >> actually resolves and loads imported.proto. Is that correct? >> > You passed in both "-I ./test" and "-I .". That confused protoc. For every > proto file protoc will use a relative path to identify it and that's also > the path used in "import" statements. For the protos passed in command > line, it will determine its path name by matching and stripping the prefix > found in "-I" arguments. So the unique name for "test/importing.proto" will > be "importing.proto" and "test/imported.proto" will be "imported.proto". > Then when compiling "importing.proto", protoc try to find the proto file in > the "import test/imported.proto" statement. "test/test/imported.proto" will > be tried first and then it finds "test/imported.proto". In the eyes of > protoc, there are 3 proto files: importing.proto, improted.proto, > test/imported.proto. The first two are in the command line and the third is > found through import statement. It then leads to the error message you see. > You can use the command line I suggested above, or you can change the > "import test/imported.proto" to "import imported.proto". Both approaches > can fix the problem. Their difference lies in the unique names of the proto > files. In the former approach, "test/importing.proto" and > "test/imported.proto" are their names and generated files will retain the > name prefix (i.e., a directory named "test" will be created in the output > path and importing.pb.cc|h imported.pb.cc|h will be put into that > directory). If using the other approach, generated files will be put > directly in the path you specified. > > >> If that's the case, then theoretically it should not be necessary to >> provide both files on command line in order to generate all required code, >> as protoc has all required info already. >> >> My question - is it possible to tell protoc that it should generate files >> for all "resolved" files by specifying in command line only top level one >> ("importing.proto") ? >> > No. > > >> >> Strictly speaking, in case of C++ it is not actually needed to have >> individual .cc/.h files for every .proto, as everything could be placed >> into single .h/.cc. I understand that this might not be possible for other >> languages, for example java, which has to respect "java_outer_classname" >> and "java_package". But for language like C++ I do not see why it is >> important to keep separate files. >> >> I am not saying that when c++ code is generated it should always place >> code generated from all included protos into single file, but merely that >> such option might be convenient in some cases. >> >> Reason I am mentioning possibility of embedding all code into single >> .h/.cc is because currently, assuming that there are two separate >> invocations of protoc to generate imported.pb.* and importing.pb.*, there >> is a sort of dependency - if I generate code like this: >> protoc --cpp_out=test -I ./test test/imported.proto >> protoc --cpp_out=test -I -I . test/importing.proto >> >> then protoc in both case will succeed, but result would not compile >> because of protobuf_AssignDesc_XXXproto names would not match. >> In other words, following has to match: >> 1. what flags (-I) I use when compiling test/imported.proto >> 2. and how test/imported.proto is imported in other files. >> > >> Situation is a bit worse in case of java, as for above example, java >> generated code would actually compile, but would give >> a java.lang.ExceptionInInitializerError at run time. >> >> Thanks >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Protocol Buffers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/protobuf?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/df5cf4f2-cce4-4900-b73c-1e8f672f08f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
