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

Catkin fails to chain workspaces [closed]

asked 2014-08-19 07:14:49 -0600

Marcel Usai gravatar image

updated 2014-08-19 16:09:03 -0600

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:


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


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/

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


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

Thanks for your support!

edit retag flag offensive 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 .

peci1 gravatar image peci1  ( 2016-11-16 09:04:44 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2014-08-19 13:13:20 -0600

dornhege gravatar image

The problem is the assumption that sourcing chains workspaces. This is not the case. If it were sourcing multiple 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/

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

$ 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/
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.

edit flag offensive delete link 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?

Marcel Usai gravatar image Marcel Usai  ( 2014-08-19 16:03:22 -0600 )edit

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).

Murilo F. M. gravatar image Murilo F. M.  ( 2014-08-19 16:38:18 -0600 )edit

answered 2014-08-19 12:40:56 -0600

Murilo F. M. gravatar image

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:


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:


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:


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:


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:


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/, /home/user/temp/B/devel/ and /home/user/temp/C/devel/, 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.

edit flag offensive delete link more


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

Marcel Usai gravatar image Marcel Usai  ( 2014-08-19 16:14:33 -0600 )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.

tianb03 gravatar image tianb03  ( 2014-11-11 05:26:55 -0600 )edit

Question Tools



Asked: 2014-08-19 05:27:18 -0600

Seen: 886 times

Last updated: Aug 19 '14