buildfarm 'make' 'install' error

Buildfarm
1

Hi, I got 2 problems

  1. Context: My package’s CMakeList.txt automatically clones and builds a library required by the package. I achieved this using “include(ExternalProject)” in CMakeList.txt, followed by INSTALL_COMMAND make install. This is setup worked fine during prerelease testing I conducted before, so I proceeded with releasing it to the buildfarm.
    However, I encountered the following error on build.ros.org :

CMake Error at /tmp/binarydeb/ros-noetic-adi-tmc-coe-1.0.0/dependencies/SOEM/src/SOEM-stamp/SOEM-install-None.cmake:49 (message):
Command failed: 2
‘make’ ‘install’

How does buildfarm handle the building of this type of package? Is there similar package that also used this method and somehow successfully builds on buildfarm?

  1. I encountered a bug on my Ubuntu (unrelated to ROS) that I needed to reinstall the OS. I want to reproduce the error (problem #1) on my local PC for debugging, but since I’ve just reinstalld the OS, I need to setup ROS and buildfarm again.
    I cannot install ros-buildfarm through sudo apt-get install python3-ros-buildfarm, as I received the error “Unable to locate package”. But I successfully installed buildfarm with pip install ros-buildfarm. Now the issue Im encountering is on ./prerelease.sh script.

ccache: error: Failed to create directory ‘/home/buildfarm/.ccache/tmp’: Permission denied

I searched about this error in google and found some discussions addressing this issue. They suggested to create the directory /home/buildfarm/.ccache and change the ownership with chown $USER:$USER /home/buildfarm/.ccache/. However, I still encounter the same error when I rerun prerelease script. Additionaly, I tried cloning buildfarm, create virtual environment, and run the prerelease script there, but the error still persist. Is there something I might be missing?

2

Is this the external project you’re mentioning?

If so, it looks like there’s already a package for SOEM in Noetic: ROS Package: soem . Remove the ExternalProject and depend on the soem package instead.

Generally vendoring dependencies in your package through ExternalProject or FetchContent is strongly discouraged. If two packages vendor different versions of the same dependency, and another package depends on both then undefined behavior can happen. For example, with C++ the one-definition rule can be violated.

Use system packages when possible. In order, the things to try are:

  1. Find an existing rosdep key on https://index.ros.org/ for the dependency you want to use, and use that
  2. If there’s no rosdep key, find an exisiting Ubuntu or Debian package for the dependnecy you want to use, and create a rosdep key for that
  3. If there’s no system package, for ROS 1 follow the REP 136 process to release the third-party package into ROS (In this case it looks like someone has already done this for soem)
3

Hi sloretz,
Yes, that’s the ExternalProject. Thanks for the reply! We’ll try to make the change.

For my second question, do you have any suggestions or idea regarding this issue? I cant use ros-buildfarm due to the error.

4

Unfortunately I don’t know how to install and use ros-buildfarm. However, if your goal is to build and test your package the same way that the buildfarm does there is https://prerelease.ros.org/noetic . It will generate a command that will run docker images to build your package on your machine in the same way as the buildfarm.

5

Hi sloretz,

I understand the restriction when using ExternalProject or FetchContent when adding dependencies in a ROS Package.

But generally speaking, let’s say that (1) there is no existing rosdep key for the dependency and (2) there is no existing Ubuntu/Debian package for the dependency, as per your suggestion, the REP-136 process should be followed.

However, in cases where the third-party package (dependency) is owned by a separate entity/company/etc, the ROS developers asked to do REP-136 may have reservations on following the REP-136 process as maintainability would then fall to the ROS developers because they (not the original authors) will automatically be tagged as Maintainers in the ROS package itself (as seen on what happened in the ROS package:: SOEM).

In some cases, licenses may also be an issue. For example, by following REP-136, ROS developers may need to create a separate upstream repository for the third-party package in order to release it into ROS distribution.

  • Will this be an issue in terms of redistribution on behalf of an entity/company? Do the ROS Developers need consent from the original authors?
  • In terms legal/misrepresentation policy on a company (ROS developer) to company (3rd party dependency developer), are we not bypassing anything?
  1. Is there another option when adding third-party packages?
  2. Is using git submodule an option when adding dependency?
  3. How about ROS 2 Packages, are the restrictions the same when adding dependencies in the package (i.e. following REP-136 is also recommended)?
6

Hi sloretz,

Thank you for all your answers.

Understood that we can use ROS Package: soem for ROS1 instead of the ExternalProject_Add(GitHub - OpenEtherCATsociety/SOEM: Simple Open Source EtherCAT Master) via <build_depend>.
Will this solution fix the cmake error that I am encountering, specifically, this one:

CMake Error at /tmp/binarydeb/ros-noetic-adi-tmc-coe-1.0.0/dependencies/SOEM/src/SOEM-stamp/SOEM-install-None.cmake:49 (message):
Command failed: 2
‘make’ ‘install’

If there’s no system package, for ROS 1 follow the REP 136 process 1 to release the third-party package into ROS (In this case it looks like someone has already done this for soem)

That means following REP 136 -- Releasing Third Party, Non catkin Packages (ROS.org) is recommended for ROS1.
However, we are also releasing the same ROS Driver this time for ROS2.

But there’s no similar “soem” package for ROS2 that we can use <build_depend> to.

In that case, what is the recommended solution?

7

It’s correct that the developers following the REP-136 process would be taking on some responsibility. That doesn’t mean they would need to fix bugs upstream, just that they would make sure it is packaged correctly (builds on the ROS buildfarm, has the right dependencies in a package.xml, etc).

These questions might be better for an attorney. I don’t know much about licensing. I don’t even know what kind of attorney should be asked.

If I understand correctly, the review guidelines for new packages to ros/rosdistro require that packages have an OSI approved license Licenses – Open Source Initiative to make sure the ROS buildfarm is allowed to distribute the software. I would guess that if a dependency has a LICENSE that forbids redistributing it via the REP-136 process, then ExternalProject or FetchContent would probably not be an option either. It seems to me that ExternalProject, FetchContent, and even git submodules would cause the ROS buildfarm to “redistribute” the software when it builds Debian packages.

If I understand correctly, the only options are to get a dependency via system packages and then add a rosdep key, or follow the REP-136 process in ROS 1. If that is not possible then the best that can be done is to use ExternalProject, FetchContent, etc and index the ROS package. People will be able to find the ROS package on https://index.ros.org, but they will have to build it from source.

I don’t have a good answer for ROS 2. There are some dependencies brought in via ament_cmake_vendor_package, but I don’t know that that is meant to be used outside of the core. I’ll ask about this in the next ROS PMC meeting.

8

Hi @sloretz ,

Thank you for your detailed response.

Some follow-up questions:

What’s the process for this? From what I understand this is different from the REP-136.

Do you have any update on this? Is REP-136 also applicable when adding dependencies to ROS 2 Packages or are there different solutions?