1
$\begingroup$

Rosanswers logo

I have these lines in my .bashrc file:

source /opt/ros/hydro/setup.bash
source /home/baxelrod/my_catkin_ws/devel/setup.bash
source /home/baxelrod/my_other_catkin_ws/devel/setup.bash

Which yields this environment variable:

ROS_PACKAGE_PATH=/home/baxelrod/my_other_catkin_ws/src:
                 /home/baxelrod/my_catkin_ws/src:
                 /opt/ros/hydro/share:
                 /opt/ros/hydro/stacks

However, when I change the order of "source" lines in my .bashrc to have "my_other_catkin_ws" before "my_catkin_ws", close and open a new terminal, then the ROS_PACKAGE_PATH becomes:

ROS_PACKAGE_PATH=/home/baxelrod/my_catkin_ws/src:
                 /opt/ros/hydro/share:
                 /opt/ros/hydro/stacks

What gives?

More info:

  • I am using ROS Hydro on Ubuntu 12.04.
  • Both catkin workspaces are compiled.
  • The workspaces were created at different times. my_catkin_ws is significantly newer than my_other_catkin_ws. (I updated my ROS packages a few times in between.) This is strange because it seems like sourcing my_catkin_ws (the newer workspace) clobbers the existing path. So it seems like maybe a bug was introduced.
  • I diffed both setup.bash and setup.sh files and there are no differences besides the path to the workspace

Originally posted by baxelrod on ROS Answers with karma: 794 on 2014-03-06

Post score: 1

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

The order of sourcing multiple setup files does not matter. Since the last one will overwrite all environment variables anyway.

What does matter is the environment you used when creating these workspaces. At the initial configure time the current environment (basically the CMAKE_PREFIX_PATH defining the already sourced workspaces which you want to overlay) is extended with the environment for this new workspace.

You can not overlay my_catkin_ws and my_other_catkin_ws by just sourcing both setup files if they been created independently in the first place.


Originally posted by Dirk Thomas with karma: 16276 on 2014-03-06

This answer was ACCEPTED on the original site

Post score: 5


Original comments

Comment by baxelrod on 2014-03-06:
Ugh. That's a pain. I really liked the old rosmake pattern of appending different directories to ROS_PACKAGE_PATH in your .bashrc. Are you saying that when you create a catkin workspace, it stores some environment variables to file? This seems dangerous.

Comment by William on 2014-03-06:
It is necessary. If you build a program in workspace B which uses a library in A, then you "add" workspace C which contains a modified version of the library in A, then when you run the program in B it will have been built against library in workspace A, but dynamically link against the library from workspace C. There are other ways this kind of workspace composing can be bad, and it will bite you eventually.

Comment by William on 2014-03-06:
You can compose them using the --extend option to the setup.* files, but use at your own risk...

Comment by Dirk Thomas on 2014-03-06:
It does not store all environment variable but only which workspace it is supposed to overlay. So basically only the CMAKE_PREFIX_PATH. The other environment variable are then generated on-the-fly when you source the setup.

$\endgroup$
0
$\begingroup$

Rosanswers logo

Check out the catkin tools package. It allows you to specify explicit workspaces to extend:

catkin config --extend /opt/ros/indigo
catkin build

makes sure that you always build the workspace with only /opt/ros/indigo as parent workspace (regardless of your current environment).


Originally posted by peci1 with karma: 1366 on 2016-11-16

This answer was NOT ACCEPTED on the original site

Post score: 2


Original comments

Comment by joq on 2016-11-16:
I highly recommend this approach. Explicitly passing the overlaid workspace avoids all the confusion caused by using the wrong environment. We all make that mistake sometimes.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.