ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

# Catkin fails to chain workspaces [closed]

Hi guys, I have a problem and cannot find a permanent solution to it:

I am trying to chain two workspaces A and B but catkin fails to recognize workspace A. So what i did was create worspace A in:

/usr/share/ros/workspaceA


This works fine and i can build my packages. Then i created another workspace B to work in, this should overlay workspace A, in:

~/ros/workspaceB


My packages in workspaceB depend on packages in workspace A. When trying

source /usr/share/ros/workspaceA/devel/setup.bash
source ~/ros/workspaceB/devel/setup.bash
cd ~/ros/workspaceB/
catkin_make


I get

...
-- This workspace overlays: ~/ros/workspaceB/devel;/opt/ros/indigo
...


and following some error that my package from workspaceA ould not be found. So obviously, catkin fails to recognize workspaceA. Without dependencies on packages from workspaceA everything works fine.

How do I get this fixed, so that i can build my packages in workspaceB? What am I missing? Has this to do with the path to workspaceA?

Note: This worked for me once, when workspaceA was located in

~/ros/workspaceA


but after deleting it and recreating in in just the same place i got the same result as above.

edit retag reopen merge delete

### Closed for the following reason the question is answered, right answer was accepted by Marcel Usai close date 2014-09-04 02:40:10.958702

This has a way nicer solution with catkin tools . See http://answers.ros.org/question/64702... .

( 2016-11-16 09:04:44 -0500 )edit

Sort by » oldest newest most voted

The problem is the assumption that sourcing chains workspaces. This is not the case. If it were sourcing multiple setup.sh files will leave you in an undefined state depending on whatever you did before. Here is your problem:

source /usr/share/ros/workspaceA/devel/setup.bash
source ~/ros/workspaceB/devel/setup.bash
cd ~/ros/workspaceB/
catkin_make


This activates workspaceB before building. Thus you do not overlay workspaceA. Check out the tutorial on chaining workspaces. Note the lines along:

## THIS IS THE CRUCIAL PART FOR OVERLAYING
$source ~/overlay_ws/devel/setup.bash$ catkin_make


You probably at some point sourced workspaceA and catkin_make in workspaceB leading to this:

-- This workspace overlays: ~/ros/workspaceB/devel;/usr/share/ros/workspaceA/devel;~/ros/workspaceB/devel;/opt/ros/indigo


Try removing the build/devel folders in workspaceB and then:

source /usr/share/ros/workspaceA/devel/setup.bash
cd ~/ros/workspaceB/
catkin_make
source ~/ros/workspaceB/devel/setup.bash


This should lead to the setup you want. From now on it is sufficient to source ~/ros/workspaceB/devel/setup.bash in your .bashrc. This will lead to the correct overlays.

more

Thank you. Think I messed things up trying to understand chaining workspaces. Just edited my question to remove the last (misleading) edit.

So one could say that it's always building before sourcing?

( 2014-08-19 16:03:22 -0500 )edit
1

That depends. Build your current workspace before sourcing it, but source other (underlaid) workspaces (which were already built at some point) before building the current one (otherwise, workspaces will not be chained).

( 2014-08-19 16:38:18 -0500 )edit

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.

more

Thank you for your answer, it just helped me understanding the concept of overlaying workspaces.

( 2014-08-19 16:14:33 -0500 )edit

Thanks for pointing out where to edit the CMAKE_PREFX_PATH. It becomes much easier for me to chain or unchain the workspaces. Thx.

( 2014-11-11 05:26:55 -0500 )edit