Issue with approach 3, that I don't understand: Generated header files 
create internal implementation functions like : 
void protobuf_InitDefaults_Baz_2eproto();

but source files using these functions are looking for:
protobuf_InitDefaults_project_2ffoo_2fBaz_2eproto(); 

When I compare the results against a build that used a defined makefile 
(not cmake), the generated header implementation matches the source call ( 
both use ...project_2ffoo_2fBaz_2eproto() ).

On Monday, November 28, 2016 at 9:47:21 AM UTC-5, Alex Shaver wrote:
>
> When I have several folders 
> top
>   \ - A
>   \ - B
>     \ - B1
>     \ - B2
> ...
>
> .With various .proto files throughout, and I run CMake (3.5.2) to generate 
> the protobuf files, it flattens the whole directory structure to just one 
> common folder. There's a few problems with this approach. 
>
>    1. If multiple proto files have the same name (say project.foo and 
>    project.bar both have baz.proto), then the compiler chokes on the 
> generated 
>    .pb.{h,cpp} files having the same name. 
>    2. Without moving the .pb.h files *back* into the same file structure 
>    (or a replicated structure elsewhere) as they were initially found in (and 
>    having to write a macro to do that), I can't use include statements like 
>    #include <project/foo/baz.h>
>    3. I've tried making each subfolder a library and then linking them 
>    together into one 'meta'-library, which fixes the first two problems, but 
>    then within protobuf the import "project/foo/baz.proto" fails because the 
>    file is in another directory. 
>       1. I think I could use PROTOBUF_IMPORT_DIRS to expand the search, 
>       but I may also have to mess with the include directories, specify 
>       dependencies, and so on. And even then, that may have trouble if there 
> are 
>       circular dependencies or something.
>    
> I can't put the proto files with the code where they're used, because the 
> protobufs are common to both C++ and Java projects. So we have to build 
> them as an independent library that we can link against with a known header 
> structure.
>
> Any thoughts or improvements on this?
>

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to