I see, yeah, you typically want to have the include path for protoc by the
root of your source tree, rather than enumerating all the different
subdirectories you want to include. I'll make a note to find a place in the
documentation to mention this; this seems to come up pretty frequently.

On Tue, Jun 5, 2012 at 9:36 AM, Dan <dashegh...@gmail.com> wrote:

> Thanks Jason, this resolves the issue.
>
> I actually have separate directories for the protobuf code as well as my
> own. I use the '-I' option when calling protoc, which I pointed at the
> directory containing 'descriptor.proto'. When I moved that path up two
> directories and made the import statement relative as you suggested the
> problem was resolved.
>
> -Dan
>
>
> On Monday, June 4, 2012 5:26:35 PM UTC-7, Jason Hsueh wrote:
>>
>> The issue is import paths - the pre-generated versions of
>> descriptor.pb.{h,cc} are generated relative to the source root. Instead of
>> importing "descriptor.proto", you should have something like
>>
>> import "google/protobuf/descriptor.**proto";
>>
>> This should make the code generator reference the declared functions in
>> descriptor.pb.h<http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/descriptor.pb.h#33>.
>> (And this way you should have separate directories for your code and the
>> google protobuf code)
>>
>> On Fri, May 25, 2012 at 11:41 AM, Dan <dashegh...@gmail.com> wrote:
>>
>>> Perhaps I am just missing something, however I am getting a compiler
>>> error that appears to be an issue with descriptor.pb.h.
>>>
>>> The error is this: "protobuf_AddDesc_descriptor_**2eproto is not a
>>> member of google::protobuf", called from "void MyPackageName::protobuf_*
>>> *AddDesc_MyMessage_2eproto()".
>>> Basically, MyMessage looks like this:
>>>
>>> package MyPackageName;
>>> import "descriptor.proto";
>>>
>>> option optimize_for = SPEED;
>>>
>>> message MyMessage
>>> {
>>>     optional google.protobuf.**FileDescriptorSet proto_set = 1;
>>> }
>>>
>>> Looking at the effect of other "import" statements I have made, it looks
>>> like the method should have been defined in descriptor.pb.h. It is not, and
>>> it does not appear that I should try to compile descriptor.proto myself.
>>>
>>> I am using version 2.4.1 of the protobuf library, and as you've probably
>>> guessed, trying to compile C++.
>>> Any ideas on how to fix this?
>>>
>>> thanks in advance,
>>> Dan
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To view this discussion on the web visit https://groups.google.com/d/**
>>> msg/protobuf/-/AcHuNhBnkzgJ<https://groups.google.com/d/msg/protobuf/-/AcHuNhBnkzgJ>
>>> .
>>> To post to this group, send email to protobuf@googlegroups.com.
>>> To unsubscribe from this group, send email to protobuf+unsubscribe@**
>>> googlegroups.com <protobuf%2bunsubscr...@googlegroups.com>.
>>> For more options, visit this group at http://groups.google.com/**
>>> group/protobuf?hl=en <http://groups.google.com/group/protobuf?hl=en>.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/protobuf/-/UYWCDtIbUPoJ.
>
> To post to this group, send email to protobuf@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com.
> 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 protobuf@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to