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

asked 2017-03-21 03:02:15 -0500

takahashi
185 ●15 ●20 ●23

updated 2017-03-21 16:23:20 -0500

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:

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.

edit retag flag offensive close merge delete

Comments

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

William ( 2017-03-21 13:19:31 -0500 )edit

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!

takahashi ( 2017-03-21 16:22:51 -0500 )edit

add a comment

answered 2017-03-22 03:29:06 -0500

takahashi
185 ●15 ●20 ●23

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.

edit flag offensive delete link

add a comment

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

Comments

1 Answer

Question Tools

Stats

Related questions

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

Comments

1 Answer

Question Tools

Stats

Related questions

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