So, let me explain exactly the problem here... > $ protoc --cpp_out=. -I../P -I../P/.. ../P/a.proto > $ protoc --cpp_out=. -I../P -I../P/.. ../P/b.proto
If you were to compile both protos with a single command: $ protoc --cpp_out=. -I../P -I../P/.. ../P/a.proto ../P/b.proto Then protoc would give you errors suggesting that "a.proto" and "P/a.proto" are defining conflicting symbols. This hints at the underlying problem: protoc cannot tell that the "../P/a.proto" you specified on the command line is the same as the "P/a.proto" that b.proto is trying to import. The problem here is that the meaning of ".." is subtle -- if foo is a symlink, then "foo/bar/.." is NOT necessarily the same as "foo". Therefore, protoc makes no attempt to collapse ".."s in order to detect when two files are actually the same file. Instead, it relies only on their canonical name relative to the import path. Unfortunately, in your case, when you pass "../P/a.proto" on the command line, protoc concludes that because "../P" is in the import path, this file's canonical name is "a.proto". But b.proto imports "P/a.proto", which must be a different file. What you actually want to do is this: $ protoc --cpp_out=. -I.. ../P/a.proto $ protoc --cpp_out=. -I.. ../P/b.proto In this case, protoc will determine that the canonical names are "P/a.proto" and "P/b.proto", which match the style you are using in your import statements. In general, you should never pass overlapping -I flags to protoc. Arguably protoc should print a warning if you do. Other than that, I'm not sure what else we could do to detect your problem. On Tue, Apr 13, 2010 at 11:24 AM, CB <[email protected]> wrote: > > Workarounds aside, there is still a bug to be fixed. > > If you wish to argue that the .proto files or the -I options I passed > to proto are invalid, then protoc should have declared an error. > > If you wish to argue that the .proto files and the -I options I passed > to proto are valid, then the c++ code emitted by protoc should have > compiled without error. > > If the error was simply an issue of -I options passed to protoc/g++ > that would be one thing, but in this case, protoc generated a call to > a function that doesn't even exist in the generated code set. That's > a major bug. > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
