source setup.bash in install space does not work when deployed onto different machine

Question

I install my catkin workspace on machine A to a directory (e.g. /home/usera/catkin_ws/install) and would like to use it on machine B in a different location (let's say a different user home, e.g. /home/userb/catkin_ws/install). My setup uses another workspace in /opt/overlay/ that is overlayed.

Now, on machine A everything works fine, when I source the setup.bash (therefore I check the ROS_PACKAGE_PATH, which is /home/usera/catkin_ws/install/share:/opt/overlay/share:/opt/ros/kinetic/share). Unfortunately, on machine B, sourcing setup.bash does not work, the ROS_PACKAGE_PATH is /opt/overlay/share:/opt/ros/kinetic/share.

I have found the following ROS answers:

• http://answers.ros.org/question/243124/deploy-ros-package/?answer=243140#post-id-243140
• http://answers.ros.org/question/226581/deploying-a-catkin-package/?answer=226725#post-id-226725

So apparently ROS uses absolute paths and I need to mirror the install location in machine A to machine B, in order to get the install space working on machine B.

So my questions are:

• Is there a way to deploy the install space to machine B to a different location than on machine A (no location mirroring)?
• If not, what is the advantage of having absolute paths? As this makes deployment of ROS binaries via an install space very cumbersome in my opinion.

---

Originally posted by takahashi on ROS Answers with karma: 185 on 2017-03-21

Post score: 0

---

Original comments

Comment by William on 2017-03-21:
opt/overlay/share:/opt/ros/kinetic/share doesn't look right, why is there no leading /? The install space should be relocatable, but the workspace it overlays needs to be on both machines (same as for binaries you built against). See: https://github.com/ros/catkin/issues/490

Comment by takahashi on 2017-03-21:
sorry, that was a typo. it is /opt/overlay/share:/opt/ros/kinetic/share of course. corrected this in the original question. the overlaid workspace is the same on both machines. I will take a look at the issue and come back with more information. thanks!

Answer 1

I resolved the problem. When I deployed my install space from machine A to machine B, I created a folder (let's call it base) containing some shell scripts and the /home/usera/catkin_ws/install and zipped it:

base - home - usera - catkin_ws - install - ...
     - a.sh
     - b.sh

More specifically, I created the zip file like this:

mkdir base
cp --parents -r /home/usera/catkin_ws/install/* base
cp a.sh b.sh  base
zip -r base.zip base

Unzipping base.zip on machine B led to the problem I described.

However, if I create the zip file like this:

mkdir base
mkdir -p base/home/usera/catkin_ws
cp -r /home/usera/catkin_ws/install base/home/usera/catkin_ws
cp a.sh b.sh  base
zip -r base.zip base

and unzip it on machine B, I can source the base/home/usera/catkin_ws/install/setup.bash and the created ROS_PACKAGE_PATH is correct.

It seems like the --parents flag of the cp command changed something in my deployed install space, however I have no idea what it changed and how this could even happen. Anyway, I am very happy that I was able to resolve this and maybe someone knows the reason of this.

---

Originally posted by takahashi with karma: 185 on 2017-03-22

This answer was ACCEPTED on the original site

Post score: 0