-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ament_export_interfaces uses absolute path / not being relocatable #173
Comments
Please provide more context what exactly you are trying to do, steps to reproduce, etc. |
In our CI, we're building the navigation2 stack against the osrf/ros2:nightly image. The procedure at a high level is to copy our repo into the docker image, At that point we get the error mentioned above. I believe this is the first time we've tried to find a package that has had an Here's our dockerfile for exact details (https://github.com/ros-planning/navigation2/blob/master/Dockerfile) |
Please post the complete error message (e.g. which package does this happen). |
Here's the complete output
I see that in |
I'm assuming that rviz_commonExport.cmake gets generated by ament. Maybe it's a cmake bug. |
I don't fully understand the details of ament yet, so this may not be relevant. But when comparing It seems like this may be the cause of the issue we are seeing. |
Neither of the two files generated by The problem might be coming from the file Within ament_cmake/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake Lines 55 to 56 in 3c432f2
And these information are certainly not relocatable. |
It doesn't look like this issue exists in the released rviz_common package. I think the problem comes down to an incompatibility between the way the OSRF build farm builds the nightly binaries and the way they are deployed in the osrf/ros2 docker image. CI installs the binaries in the local workspace, but the docker image installs them under /opt/ros instead. From CMake's perspective, all the rviz_common's external dependencies have been relocated, and that doesn't seem to be supported by CMake. Given that, I think you can close this issue here. The problem more appropriately belongs with the Dockerfile, I believe. |
That conclusion is incorrect. The problem is that the resulting CMake code for the imported target isn't relocatable. In the case of Docker I assume the files aren't being relocated hence it works. The packages in the archive are certainly built in a different location than the user unpacks them to and therefore are relocated. Since the generated CMake code contains absolute paths that will break. |
It seems the generated CMake code allows rviz_common to be relocated. It just doesn't allow rviz_common's dependencies to be relocated. Those are the hard-coded paths. But those dependencies have been relocated in this case, because the dependencies are other ros packages. The actual paths in the generated CMake code are a mix of system dependencies and other ros packages. To make this truly relocatable, CMake would need to be informed which dependencies should be specified with relative paths and which with absolute. That might be possible in CMake, but I haven't found a way to do that yet. |
After having recently worked on interface targets (#231, #232, #235) I am pretty certain that exported interface targets (the modern CMake way) are relocatable if and only if they only use interface targets from dependencies. If at least one of the dependencies doesn't support interface targets but only provides So the actual bug in this case is that Therefore I will go ahead and close this ticket. Please feel free to continue commenting. |
When trying to
find_package(rviz_common)
, I get the following errorThis happens when I try to build using
osrf/ros2:nightly
docker image or just usehttps://ci.ros2.org/view/packaging/job/packaging_linux/lastSuccessfulBuild/artifact/ws/ros2-package-linux-x86_64.tar.bz2
directly.I believe the problem is that the binary packages are built in a certain location on the CI machine. When they get extracted to the new location in the docker image or on my local machine, the path is now incorrect. It seems there is a variable used in the setup scripts (
COLCON_CURRENT_PREFIX
) that is supposed to override the as-built path, but it doesn't seem to work for theINTERFACE_INCLUDE_DIRECTORIES
variable.The text was updated successfully, but these errors were encountered: