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

Standalone deployment of catkin install space

asked 2018-10-30 09:40:57 -0500

jdlangs gravatar image

updated 2018-10-30 09:43:45 -0500

I am currently trying to deploy a catkin workspace to a remote machine by bundling the contents of the install space into an installation package. My hope was that I could unpack the files on the machine, run setup.bash and everything would work fine no matter where the workspace was.

Instead, I'm discovering that the environment setup scripts have the workspace path from my development machine hardcoded in them and that path is being added to CMAKE_PREFIX_PATH. Specifically, in the generated _setup_util.py, I see right after argument parsing (line 264):

    # environment at generation time
    CMAKE_PREFIX_PATH = '/home/jlangsfeld/dev_workspace/install;/opt/ros/kinetic'.split(';')
    # prepend current workspace if not already part of CPP
    base_path = os.path.dirname(__file__)
    if base_path not in CMAKE_PREFIX_PATH:
        CMAKE_PREFIX_PATH.insert(0, base_path)
    CMAKE_PREFIX_PATH = os.pathsep.join(CMAKE_PREFIX_PATH)

This doesn't make sense to me because the dev_workspace should come from the second half of this code snippet; why is it hardcoded in? If I delete the dev_workspace entry in the string then my CMAKE_PREFIX_PATH becomes what I want it to be but surprisingly, packages in the deployed workspace cannot be found.

Am I doing something wrong here or is something not working as expected?

Edit: possibly related to #285009

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-10-30 10:12:28 -0500

allenh1 gravatar image

updated 2018-10-30 10:52:14 -0500

I'm not sure how others feel, but I see this usage as incorrect. You should not be deploying a catkin workspace like this, IMHO.

I do have an idea that could bring the desired affect, however. I think it would be best to try vcs out.

On first machine:

cd catkin_ws
vcs export src > catkin.repos

On the second machine:

mkdir -p catkin_ws/src
cd catkin_ws/src && catkin_init_workspace
cd ..
vcs import src < catkin.repos
catkin_make

this will get you the contents of the other workspace in something you can just host as a GitHub gist.


If you're not interested in deploying source, you can try deploying .deb files instead, following this answer.

edit flag offensive delete link more

Comments

Can I ask you to expand the first part of your answer with explanation and/or alternatives? It doesn't give me (or future question readers) a path forward just to say I'm doing it wrong. I also want to keep the scope to deploying the install space; I'm not interested in deploying source code.

jdlangs gravatar image jdlangs  ( 2018-10-30 10:32:38 -0500 )edit

@jdlangs I was trying to express that it isn't a great idea to deploy a workspace, due to the fact that there are hardcoded paths (by design) in the setup scripts.

allenh1 gravatar image allenh1  ( 2018-10-30 10:51:33 -0500 )edit

An alternative is to deploy not in the user home but a place that is the same on each (Ubuntu) machine. This is install to, e.g. /opt/ros/my_workspace. See details on how to do this here. Then you can copy this location to the other machine.

mgruhler gravatar image mgruhler  ( 2018-10-30 10:56:22 -0500 )edit

@allenh1 Are you aware of any documentation/discussion out there that explains the hardcoding? @mgruhler Thanks for the link, this looks like the best option I'll have.

jdlangs gravatar image jdlangs  ( 2018-10-30 11:28:44 -0500 )edit
2

Just an observation: copying binary artefacts from one machine to another without some form of package and/or dependency management is a fragile process, as different versions and/or locations of libraries and the presence/absence of certain libraries will influence the success of such an operation.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-30 15:52:09 -0500 )edit
2

Creating redistributable archives (ie: .debs for Ubuntu/Debian platforms) is almost always a better idea.

For embedded systems, building a rootfs with the proper tools would be comparable.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-30 15:52:33 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2018-10-30 09:40:57 -0500

Seen: 557 times

Last updated: Oct 30 '18