[cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy

ابراهیم محمدی mebrahim at gmail.com
Mon May 26 15:46:08 EDT 2014


I think the user is supposed not to pass full paths to
PROTOBUF_GENERATE_CPP. Because if user does so, there is a more severe bug
right now in the code: if user provides both /some/path/A.proto and
/another/path/A.proto to PROTOBUF_GENERATE_CPP, C++ file of both A.proto
files will be generated in ${CMAKE_CURRENT_BINARY_DIR}/A.cpp. In other
words C++ file of one A.proto overwrites C++ of the other A.proto file.

So I think the original author of FindProtobuf.cmake has intended the user
to provide relative paths to .proto files, and he/she has been mostly
considering cases where .proto files are placed right in the same directory
as CMakeLists.txt, rather than more complex cases like .proto files
organized in a directory hierarchy which I'm recently hit a bug about. On
the other hand I can't think of a genuine use case where user needs to use
PROTOBUF_GENERATE_CPP on absolute paths.

Long story short I think it is safe to assume PROTOBUF_GENERATE_CPP is
intended to be used on relative paths. But again maybe I'm missing
something! So correct me if I'm wrong. :)


On Mon, May 26, 2014 at 11:58 PM, David Cole <dlrdave at aol.com> wrote:

> Maybe I'm missing something. Is it guaranteed that all callers of
> PROTOBUF_GENERATE_CPP will pass non-full-path names for the .proto source
> files?
>
> If so, then I retract my statement. But I don't think you can guarantee
> that.
>
>
> David C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140527/a04836e4/attachment-0002.html>


More information about the cmake-developers mailing list