protoc ProtoBuf compiled is not found by default CMake script
Describe the bug Running the following CMake script:
find_package(Protobuf REQUIRED)
# Make sure protoc is present, as apparently the above find_package() doesn't check that.
if(NOT PROTOBUF_PROTOC_EXECUTABLE)
message(FATAL_ERROR "Cannot find required 'protoc', cannot process Protobuf files without it. Aborting.")
endif()
results in a failure because the protoc is not found.
To Reproduce Run the script reported before.
Expected behavior
protoc should be found.
Environment information:
- OS version:
winverVersion 1909 18363.778 - Chocolatey Versions:
choco list --local-only
C:\src\abb_libegm\build_ros>choco list --local-only
Chocolatey v0.10.15
boost 1.66.0.1904102339
bzip2 1.0.6.1901242108
chocolatey-core.extension 1.3.5.1
chocolatey-windowsupdate.extension 1.0.4
console_bridge 0.4.0.1809242322
cppunit 1.12.1.1809242322
eigen 3.3.4.1809242322
google-mock 1.8.0.1809242326
google-test 1.8.0.1809242322
KB2919355 1.0.20160915
KB2919442 1.0.20160915
KB2999226 1.0.20181019
KB3033929 1.0.5
KB3035131 1.0.3
libgraphviz 2.41.0.1810022039
log4cxx 0.10.0.1809242322
lz4 1.8.1.1809242322
openssl 1.1.1.1809242322
pkg-config 0.29.2.1809242322
poco 1.8.1.1809242322
protobuf 3.6.1.1811130545
ros-catkin-tools 0.0.1.1903221831
ros-melodic-robot 20200501.1
ros-python2 2.7.15.1904300710
ros-vcpkg 2018.11.23.1906112226
sbcl 0.0.0.1809242326
sip 4.19.8.1809242322
tinyxml 2.6.2.1809242322
tinyxml2 6.1.0.1809242322
urdfdom 1.0.0.1809242322
urdfdom_headers 1.0.0.1809242322
vcpython27 9.0.30729.1809090720
vcredist140 14.25.28508.3
vcredist2010 10.0.40219.2
yaml-cpp 0.6.2.1901170034
35 packages installed.
C:\src\abb_libegm\build_ros>
This happens because protoc is installed in C:/opt/rosdeps/x64/tools/protobuf/, but this directory is not added in any directory that can be found via find_program, for example is not appended to the PATH or CMAKE_PROGRAM_PATH enviroment variables.
Hello @traversaro , The google cartographer cmakefile has an example of how to refer to protobuf in a ROS project: https://github.com/cartographer-project/cartographer/blob/bcd5486025df4f601c3977c44a5e00e9c80b4975/CMakeLists.txt#L42
Hi @ooeygui,
I was aware of the possibility of using the protobuf-installed CMake module and protobuf_MODULE_COMPATIBLE, but I think that forcing its use instead of fixing ROSOnWindows so that the normal find_package(Protobuf REQUIRED) works is a workaround rather then a solution, for the following reasons:
- The fact that, differently from all other systems, you need to use
find_package(Protobuf 3.0.0 CONFIG)on ROSOnWindows is not documented anywhere, and it is typically confusing for users, see for example https://github.com/ros-industrial/abb_libegm/pull/63/files#r366947286 and https://github.com/protocolbuffers/protobuf/issues/4806#issuecomment-399326674 . - The protobuf-installed CMake module does not support well the case in which both Protobuf 2 and Protobuf 3 are installed in the prefix (see for a related PR https://github.com/cartographer-project/cartographer/pull/1529)
- The implementation of
protobuf_generate_cppmacro in the protobuf-installed CMake module is behaving different from the one provided in theFindProtobuf.cmakefor protofiles contained in directories different from the one in which they are processed by CMake, leading to extremely subtle bugs. While this is strictly speaking a protobuf bug that I will report on their issue tracker, I think that it can be easily mitigated by making sure thatprotoccan be found on ROSOnWindows like is found on all other operating systems or package managers.
To clarify, what to do think are the downside of the proposed fix of adding C:/opt/rosdeps/x64/tools/protobuf to CMAKE_PROGRAM_PATH ? As far as I know, the tools\protobuf directory to install protoc was introduced by vcpkg, and in that case what they do is exactly to add that directory to CMAKE_PROGRAM_PATH, see https://github.com/microsoft/vcpkg/blob/2020.04/scripts/buildsystems/vcpkg.cmake#L211 .
An even simple alternative is just to move protoc.exe from C:/opt/rosdeps/x64/tools/protobuf/ to C:/opt/rosdeps/x64/bin, as the original vcpkg rationale to have a separate directory for executables is to not put .exe files in the /bin for cross-compilation scenario, but given that in ROSOnWindows case C:/opt/rosdeps/x64/bin is already full of executables, I see no reason to keep protoc in a different directory.
Note that the solution of adding C:\opt\rosdeps\x64\tools\protobuf to the PATH has been used in the Gazebo build scripts: https://github.com/ms-iot/ros-windows-build/blob/2575093c08c39b68ffde7b4525bf669469101ac0/gazebo/gazebo9/azure-pipelines.yml#L45
so it could make sense to just include that in the environment for all the developers.
cc @seanyen
I'm reopening; I'll take a look at this again.