Multiple dependent local packages conflicting with installed ones
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
andB
both depend on somecatkin
imports (likestd_msgs
) and nothing elseC
depends on bothA
andB
D
depends onC
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
Asked by ALTinners on 2019-09-11 02:29:11 UTC
Comments
I would not do that. While not all tools use
ROS_PACKAGE_PATH
, some do, and having an inconsistentROS_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.Asked by gvdhoorn on 2019-09-11 02:48:20 UTC
@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 - resettingROS_PACKAGE_PATH
to nil, sourcing the mainsetup.bash
and running the build again shows no difference - the transitive include paths still end up ordered the same wayAsked by ALTinners on 2019-09-11 03:45:33 UTC
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).Asked by gvdhoorn on 2019-09-11 03:53:43 UTC
Also found #q331158 with a similar problem with include order
Asked by ALTinners on 2019-09-11 04:03:33 UTC