I think if you run everything from the root of your imports this all goes away. The protobuf_AddDesc_* functions are file-level methods used to initialize various bits of static data. The names for these methods are generated based on the pathname of the .proto. When b.proto imports a.proto, it needs to invoke a.proto's AddDesc method to make sure that a's static data is initialized first. It figures out the name of the function based on the import location, which in your case is "../P/../P/a.proto" - that leads to the extra P_2f in b.pb.cc.
If instead you ran $ protoc --cpp_out=./P -I./ P/a.proto $ protoc --cpp_out=./P -I./ P/b.proto then I believe everything will come out consistently. There's no requirement that the package name correspond to the path name -you just need to make sure the path names match up. On Tue, Apr 13, 2010 at 7:31 AM, CB <[email protected]> wrote: > part of our coding standard is that includes/imports take form; > > import "<package name>/<file name>" > > using this style yields compile errors for protobuf. Here's example > code > > --- A.proto --- > > package P; > > message A { } > > --- B.proto --- > > import "P/A.proto"; > > package P; > > message B { optional A a = 1; } > > --- compile commands, in folder P --- > > $ protoc --cpp_out=. -I../P -I../P/.. ../P/a.proto > $ protoc --cpp_out=. -I../P -I../P/.. ../P/b.proto > $ g++ -I../P -I../P/.. -c b.pb.cc -o b.pb.o > b.pb.cc: In function ‘void P::protobuf_AddDesc_b_2eproto()’: > b.pb.cc:74: error: ‘protobuf_AddDesc_P_2fa_2eproto’ is not a member of > ‘P’ > > why all the dots? it's an automake build using $(srcdir) for the -I's. > > --- workaround --- > > Remove the <package name> from the import statement. > > --- problem --- > > The method in question can be seen in a.pb.h as; > > a.pb.h: friend void protobuf_AddDesc_a_2eproto(); > > which lacks the 'P_2f' package specifier that gets folded into the > method name in b.pb.cc. > > What's even more fun, is putting message A in foo.proto, and changing > the import in b to; > > import "P/foo.proto"; > > which yields; > > foo.pb.h: friend void protobuf_AddDesc_foo_2eproto(); > b.pb.cc:74: error: ‘protobuf_AddDesc_P_2ffoo_2eproto’ is not a member > of ‘P’ > > This all seems to rely on the Java path=package and filename=classname > paradigms, which don't hold for C/CPP. > > -- > 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.
