ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Sourcing in the correct order does not actually guarantee workspaces will be chained correctly, and the ROS_PACKAGE_PATH may have repeated entries (as described in the question). The details can be found here. This link also describes the limitations in chaining catkin workspaces.

It is all down to which ROS installation and user workspace(s) were already sourced at the time the new workspace was created.

To illustrate that, suppose the .bashrc file is only sourcing my hydro (or indigo) installation:

source /opt/ros/hydro/setup.bash

We can check the environment variable:

$ echo $ROS_PACKAGE_PATH
/opt/ros/hydro/share:/opt/ros/hydro/stacks

Then, in terminal #1 we create a workspace named A, build and source it:

$ mkdir -p ~/A/src
$ cd ~/A/src
$ catkin_init_workspace
...
$ cd ../
$ catkin_make
...
$ source devel/setup.bash

If we check the environment variable again:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/A/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

In (a new) terminal #2, we create another workspace, named B (remember, only the system-wide ROS installation is being sourced in my .bashrc). After building and sourcing it in terminal #2, if we check the env. variable in this case:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/B/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

So far so good. Let us now add the necessary lines to the .bashrc file in order to source workspaces A and B:

source /opt/ros/hydro/setup.bash
source /home/user/temp/A/devel/setup.bash
source /home/user/temp/B/devel/setup.bash

Again, in (a new) terminal #3, if we check the env. variable:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/B/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

Only workspace B (as well as the system-wide installation) was sourced. This shows that sourcing in the correct order does not imply in chaining workspaces correctly (as documented in the link above).

Now, back to terminal #1, where workspace A is properly sourced, let us create workspace C, build and source it. Then, let us check the environment variable:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/C/src:/home/user/temp/A/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

This time, workspace C was correctly chained with workspace A, and the reason for that to have worked as expected is because workspace A was already sourced in terminal #1, which was not the case in terminal #2.

To be more pedantic with my explanation, if one tried the sequence of commands above and ran a diff (say, using meld) between the automatically generated files /home/user/temp/A/devel/_setup_util.py, /home/user/temp/B/devel/_setup_util.py and /home/user/temp/C/devel/_setup_util.py, one would find that those files from workspaces A and B are identical, whilst in the file referring to workspace C, line 255, the CMAKE_PREFIX_PATH variable would include /home/user/temp/A/devel, because workspace A was already sourced.

I hope this helps others to avoid having the issues I had in the past.