Skip to content
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

Work around rviz_common import error #806

Conversation

crdelsey
Copy link
Contributor

@crdelsey crdelsey commented Jun 5, 2019


Basic Info

Info Please fill out this column
Ticket(s) this addresses fixes #799
Primary OS tested on Ubuntu
Robotic platform tested on NA

Description of contribution in a few bullet points

  • Nightly build tarball used in the osrf/ros2 docker image has hardcoded paths to the ROS 2 build farm's install location. This specifically is a problem for packages that use the ament_export_interfaces mechanism such as rviz_common. When trying to import that package using find_package(rviz_common REQUIRED), we get the error
Imported target "rviz_common::rviz_common" includes non-existent path

    "/home/jenkins-agent/workspace/packaging_linux/ws/install/include"
  • To work around that problem, this PR creates the invalid path in the docker image and symlinks it to the real ros2 location.

@mjeronimo mjeronimo added the nav2_lifecycle Related to the manged/lifecycle node implementation label Jun 5, 2019
@ruffsl
Copy link
Member

ruffsl commented Jun 5, 2019

That's one workaround. Is this issue with ament_export_interfaces being tracked upstream at all, or is this entirely as expected? For the sake of portability, I might suggest we introduce this symlink in osrf/ros2:nightly so that all the little hacks tweaks to replicate a conventional ROS2 install are co-located upstream. @nuclearsandwich @mikaelarguedas ?

@crdelsey
Copy link
Contributor Author

crdelsey commented Jun 5, 2019

I filed an issue in the ament_cmake repo. ament/ament_cmake#173

@dirk-thomas and I were discussing where the right place to fix this is. In the meantime, anyone using the nightly image and trying to import packages that use the export_interfaces mechanism will run into this problem, so working around this in the official nightly docker file would be a good thing, IMHO.

@crdelsey
Copy link
Contributor Author

crdelsey commented Jun 6, 2019

Closing since this is fixed up stream

@crdelsey crdelsey closed this Jun 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
nav2_lifecycle Related to the manged/lifecycle node implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants