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 <dlrd...@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. > >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
