Question

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

Asked by jdlangs on 2018-10-30 09:40:57 UTC

Answer 1

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.

Asked by allenh1 on 2018-10-30 10:12:28 UTC

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.

Asked by jdlangs on 2018-10-30 10:32:38 UTC

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

Asked by allenh1 on 2018-10-30 10:51:33 UTC

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.

Asked by mgruhler on 2018-10-30 10:56:22 UTC

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

Asked by jdlangs on 2018-10-30 11:28:44 UTC

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.

Asked by gvdhoorn on 2018-10-30 15:52:09 UTC

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.

Asked by gvdhoorn on 2018-10-30 15:52:33 UTC

Standalone deployment of catkin install space

Comments

Answers

Comments