Sourcing an explicitly extended workspace does not overwrite RTT_COMPONENT_PATH

[ahoarau]

Let's say I have :

• workspace A that extends /opt/ros/kinetic ( with command catkin config -e /opt/ros/kinetic)
• workspace B that extends /opt/ros/kinetic ( with command catkin config -e /opt/ros/kinetic)

If I source A's setup.bash I'll have ROS_PACKAGE_PATH = /path/to/A/install/share:/opt/ros/kinetic/share

If in the same terminal I source B I'll have ROS_PACKAGE_PATH = /path/to/B/install/share:/opt/ros/kinetic/share

But
Sourcing A workspace gives :
RTT_COMPONENT_PATH = /path/to/A/install/lib/orocos

Sourcing B right after workspace gives :
RTT_COMPONENT_PATH = /path/to/A/install/lib/orocos:/path/to/B/install/lib/orocos

One would expect RTT_COMPONENT_PATH = /path/to/B/install/lib/orocos

EDIT : Same for CMAKE_PREFIX_PATH
Source A ---> /path/to/A/install:/opt/ros/kinetic
Source B right after ---> /path/to/B/install:/opt/ros/kinetic

[meyerj]

This is intended behavior from looking at env-hooks/00.rtt.sh.in.

catkin-generated setup.sh scripts remove workspaces that have been sourced before from the environment (from CMAKE_PREFIX_PATH, ROS_PACKAGE_PATH, etc.), but only if it still exists and has a .catkin marker file. Other paths which are not detected as catkin workspaces will remain at the end of the list. We could do the same for RTT_COMPONENT_PATH, but the shell script would become more complex (taking into account compatibility with various shells). Alternatively we could simply reset the RTT_COMPONENT_PATH before iterating over the CMAKE_PREFIX_PATH as set by catkin, but that approach would also remove custom component paths set by the user before sourcing the workspace's setup.bash. Because most ROS users probably would not add custom paths to the RTT_COMPONENT_PATH, I think this would be an acceptable option.

[ahoarau]

As a user point of view, if I explicitly source a workspace, then it's normal that the variables are somehow reset.
I vote for resetting RTT_COMPONENT_PATH before 👍