gmock issue building realtime_tools on arch linux

I’m trying to build ros-melodic-realtime-tools from the arch linux AUR. The PKGBUILD shows how the make commands are called.

I get the following error:

$ makepkg
==> Making package: ros-melodic-realtime-tools 1.15.0-0 (Mon 09 Sep 2019 01:57:27 AM CDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found ros-melodic-realtime-tools-1.15.0.tar.gz
==> Validating source files with sha256sums...
    ros-melodic-realtime-tools-1.15.0.tar.gz ... Passed
==> Extracting sources...
  -> Extracting ros-melodic-realtime-tools-1.15.0.tar.gz with bsdtar
==> Removing existing $pkgdir/ directory...
==> Starting build()...
-- Using CATKIN_DEVEL_PREFIX: /home/jwhendy/installed/build/ros-melodic-aur/ros-melodic-realtime-tools/src/build/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/melodic
-- This workspace overlays: /opt/ros/melodic
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Using default Python package layout
-- Using empy: /usr/lib/python3.7/site-packages/em.py
-- Using CATKIN_ENABLE_TESTING: ON
-- Skip enable_testing() when building binary package
-- Using CATKIN_TEST_RESULTS_DIR: /home/jwhendy/installed/build/ros-melodic-aur/ros-melodic-realtime-tools/src/build/test_results
-- Found gtest: gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-3.7
-- catkin 0.7.17
-- BUILD_SHARED_LIBS is on
CMake Warning at /opt/ros/melodic/share/catkin/cmake/test/gtest.cmake:151 (message):
  skipping gmock 'realtime_box_tests' in project 'realtime_tools' because
  gmock was not found
Call Stack (most recent call first):
  /opt/ros/melodic/share/catkin/cmake/test/gtest.cmake:80 (_catkin_add_executable_with_google_test)
  /opt/ros/melodic/share/catkin/cmake/test/gtest.cmake:54 (_catkin_add_google_test)
  CMakeLists.txt:23 (catkin_add_gmock)


CMake Error at CMakeLists.txt:24 (target_link_libraries):
  Cannot specify link libraries for target "realtime_box_tests" which is not
  built by this project.


-- Configuring incomplete, errors occurred!
See also "/home/jwhendy/installed/build/ros-melodic-aur/ros-melodic-realtime-tools/src/build/CMakeFiles/CMakeOutput.log".
See also "/home/jwhendy/installed/build/ros-melodic-aur/ros-melodic-realtime-tools/src/build/CMakeFiles/CMakeError.log".

I made a slight edit to a function to see where it was looking.

$ cat /opt/ros/melodic/share/catkin/cmake/test/gtest.cmake
function(_catkin_add_executable_with_google_test type target)
...
  if(NOT ${type_upper}_FOUND AND NOT ${type_upper}_FROM_SOURCE_FOUND)
    message(WARNING "skipping ${type} '${target}' in project '${PROJECT_NAME}' because ${type} was not found in '${GTEST_INCLUDE_DIRS}'")

This prints out as:

skipping gmock 'realtime_box_tests' in project 'realtime_tools' because
  gmock was not found in '/usr/include'

I do have gmock/gtest installed, and the dirs are in /usr/include. For the heck of it, I tried symlinking all *.h files into /usr/include directly, but that didn’t work out.

$ pacman -Qi gmock
Name            : gmock
Version         : 1.8.1-3

$ pacman -Qi gtest
Name            : gtest
Version         : 1.8.1-3

$ ls /usr/include/gmock/
internal         gmock-cardinalities.h      gmock-generated-function-mockers.h  gmock-generated-nice-strict.h  gmock-matchers.h      gmock-more-matchers.h
gmock-actions.h  gmock-generated-actions.h  gmock-generated-matchers.h          gmock.h                        gmock-more-actions.h  gmock-spec-builders.h

I think this is related to #933 and #970. I also saw #1022 and adapted ros-melodic-catkin to build from @sloretz 's fork, but this did not solve my issue. I get the same original error about gmock not being found.

Any other details that would be helpful, or debug output I could add to assist with this?

[sloretz]

Reopening since I don’t think #1040 is expected to resolve the issue on Arch.

[jwhendy]

This sounds like you are implying that you have already done some work and are expecting that other will now jump in and help out on the missing parts. hat is unfortunately not an expectation I can meet.

Hopefully you agree I have already done some work (as I’ve measured many hours of it), and I appreciate the correction on what you’re able to provide. When I see an issue follow-up, I do tend to assume that a maintainer would like to resolve it.

I am happy to comment were I can and where the information I am being given is sufficient for me to come up with a helpful opinion.

I think this is all I want as well. I’m happy to insert message() output to tell you what’s going on, but learning catkin internals and cmake from scratch is also not an expectation I can meet in order to debug something. I’m contributing time out of charity to help experts, ideally, see something that stands out as weird. Then I have something to go by. Currently I’ve received no feedback on actual findings to say whether or not they look correct or not.

From your previous comment that conclusion was not that obvious to see - this statement was much more clear.

Yay! I like progress. Thanks for summarizing this nicely.

I would advise to compare what happens on an Ubuntu machine (literally checking the complete flow of the CMake logic and the value of every variable) and compare that to what happens on Arch.

I’m game, and dual boot bionic. At face value to a noob, I imagine putting message() lines everywhere… is there a more “pro” way to do said trace?

I would suggest to you to separate these different aspects to simplify the problem to troubleshoot.

I mostly agree, especially after seeing /usr/src/gtest/src and not seeing this directory for gmock. That seems like a goof. That said, I was inclined to identify the minimum changes necessary to fix arch, then diagnose the best solution. For example, if other distros use /usr/srcr/gmock/*.cc (vs. putting in src/*.cc), maybe there is a case for just adding the path to existing paths (otherwise you’ll duplicate this next time a non-debian distro pops up). In any case, the current path seems good and I’ll summarize what I find.

We appreciate and value any kind of contribution. It would be great if you continue that work to resolve this problem on Arch.

Your response this time seemed much more concrete and helpful, and I appreciate that. I didn’t want to get into a cycle of posting a bunch of work that no one had any time to read, which is what previous interactions felt like. I really appreciate the pointers and am happy to continue tracking this down.