Multiple dependent local packages conflicting with installed ones

asked 2019-09-11 02:29:11 -0500

ALTinners gravatar image

Say I have 4 packages that I maintain, and wish to keep both an installed version and a local source version on my machine - installed for day-to-day work and source for testing features.

For these packages A, B, C, D

  • A and B both depend on some catkin imports (like std_msgs) and nothing else
  • C depends on both A and B
  • D depends on C

I set my ROS_PACKAGE_PATH=/local/workspace/path/src:/opt/ros/{distro}/share so that roscd will go to the workspace, not the install folder.

In my CMakeLists for A and B I have a CATKIN_DEPENDS descriptor which lists the catkin imports it uses, so these can be passed transitively to C. C in turn has its CATKIN_DEPENDS on A and B so these can be passed onto D.

Inside of D's CMakeLists - if I print out the INCLUDE_DIRS variable for C I get something like

  • /local/workspace/path/to/C
  • /local/workspace/path/to/A
  • /opt/ros/{distro}/include
  • /local/workspace/path/to/B

Inside of C's CMakeLists - the INCLUDE_DIRS for A and B both include /opt/ros/{distro}/include - I assume CATKIN_DEPENDS strips out the duplicate lines on a first-in basis.

Given that all 4 of the packages are installed locally as well as in the workspace - the 3rd include prevents B from ever being found locally - even though the linking seems to find the correct locally generated lib.

Are there any solutions that allow transitive dependencies to work well like this and have the workspace-includes be preferred?

FWIW I am building with kinetic and catkin_make

edit retag flag offensive close merge delete

Comments

I set my ROS_PACKAGE_PATH=/local/workspace/path/src:/opt/ros/{distro}/share so that roscd will go to the workspace, not the install folder.

I would not do that. While not all tools use ROS_PACKAGE_PATH, some do, and having an inconsistent ROS_PACKAGE_PATH compared to (fi) CMAKE_PREFIX_PATH may lead to some strange problems.

I'm not claiming it's the cause of what you describe, but I would undo that change to your ROS_PACKAGE_PATH and verify you observe the same behaviour without it.

After a successful build, your ROS_PACKAGE_PATH will be automatically set for you.

gvdhoorn gravatar imagegvdhoorn ( 2019-09-11 02:48:20 -0500 )edit

@gvdhoorn I get the feeling that ROS_PACKAGE_PATH only means things in the context of the ROS bash environment - catkin doesn't appear to use it. In any case - resetting ROS_PACKAGE_PATH to nil, sourcing the main setup.bash and running the build again shows no difference - the transitive include paths still end up ordered the same way

ALTinners gravatar imageALTinners ( 2019-09-11 03:45:33 -0500 )edit

At least now we know.

As to what you describe: #q204181 seems related and catkin/catkin_tools#547 as well (it's in catkin_tools but describes the same / a similar problem).

gvdhoorn gravatar imagegvdhoorn ( 2019-09-11 03:53:43 -0500 )edit

Also found #q331158 with a similar problem with include order

ALTinners gravatar imageALTinners ( 2019-09-11 04:03:33 -0500 )edit