Why is swri_transform_util failing to build in ROS 2 Dashing on the build farm?

Question

I've released the marti_common repository into ROS 2 Dashing on the build farm, and most of the packages build fine, but swri_transform_util fails to build: http://build.ros2.org/job/Dbin_uB64__swri_transform_util__ubuntu_bionic_amd64__binary/

It seems to be failing when cmake is running because it is trying to compile a test program that links in "pthreads", which of course makes sense because that doesn't exist. swri_transform_util does use Boost::thread, and as far as I can tell, that is declared properly in its package.xml and CMakeLists.txt.

I can also build the deb myself from the ros2-testing source repository in a clean ros:dashing Docker container; in fact, here's a simple Dockerfile that does so:

FROM ros:dashing

RUN echo 'deb http://packages.ros.org/ros2-testing/ubuntu bionic main' >> /etc/apt/sources.list.d/ros2-latest.list
RUN echo 'deb-src http://packages.ros.org/ros2-testing/ubuntu bionic main' >> /etc/apt/sources.list.d/ros2-latest.list

RUN apt-get update && \
    apt-get install -y apt-src && \
    apt-src install ros-dashing-swri-transform-util && \
    apt-src build ros-dashing-swri-transform-util && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

This builds without error, and I can't figure out what the build farm is doing differently that is causing it to fail. In fact, the output seems the same; inside the Docker image, /ros-dashing-swri-transform-util-3.0.1/obj-x86_64-linux-gnu/CMakeFiles/CMakeError.log contains the same pthreads-related error messages that I see on the build farm, but for some reason that did not cause apt-src to exit and flag the build as a failure.

Does anybody have any idea what's going wrong here? Thanks in advance!

---

Originally posted by preed on ROS Answers with karma: 88 on 2019-11-11

Post score: 0

Answer 1

The actual error message you are looking for is way further up in the console output: http://build.ros2.org/job/Dbin_uB64__swri_transform_util__ubuntu_bionic_amd64__binary/2/console#console-section-1:

00:05:36.611 CMake Error at CMakeLists.txt:90 (find_package):
00:05:36.611   By not providing "Findament_cmake_gtest.cmake" in CMAKE_MODULE_PATH this
00:05:36.611   project has asked CMake to find a package configuration file provided by
00:05:36.611   "ament_cmake_gtest", but CMake did not find one.
00:05:36.611 
00:05:36.611   Could not find a package configuration file provided by "ament_cmake_gtest"
00:05:36.611   with any of the following names:
00:05:36.611 
00:05:36.611     ament_cmake_gtestConfig.cmake
00:05:36.611     ament_cmake_gtest-config.cmake
00:05:36.611 
00:05:36.611   Add the installation prefix of "ament_cmake_gtest" to CMAKE_PREFIX_PATH or
00:05:36.611   set "ament_cmake_gtest_DIR" to a directory containing one of the above
00:05:36.611   files.  If "ament_cmake_gtest" provides a separate development package or
00:05:36.611   SDK, be sure it has been installed.
00:05:36.611 
00:05:36.611 
00:05:36.613 -- Configuring incomplete, errors occurred!

The reason is that the swri_transform_util package tries to use ament_cmake_gtest (https://github.com/swri-robotics/marti_common/blob/c56d91c8e13156f50a72b33cff1e8e0ba0224e19/swri_transform_util/CMakeLists.txt#L90) but doesn't declare a (test) dependency on it in the package manifest.

---

Originally posted by Dirk Thomas with karma: 16276 on 2019-11-11

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by preed on 2019-11-11:
Ah, oops! Thanks for catching that. I should just remove that for the moment since I don't have the tests working anyway. Although, do you know why that would cause it to fail on the build farm but not in a standalone container?

Comment by Dirk Thomas on 2019-11-11:
It depends on how your underlay was build. If it uses isolation (each package having a separate directory under install) it would have failed locally to. If your underlay uses a merged install then depending on any other package will pull in the same base path and ament_cmake_gtest can be found in the same location.