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

Extend colcon workspace without sourcing setup.sh

asked 2019-01-14 19:04:33 -0500

ruffsl gravatar image

Using colcon, is there a way to Explicitly Specifying Workspace Chaining without sourcing the parent workspace directly via setup.sh? With catkin_tools, there exists the --extend; is there a colcon equivalent? I didn't see anything of link in the migration guide:

https://colcon.readthedocs.io/en/rele...

Or is sourcing install/setup.sh the conventional approach going forward?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2019-01-15 10:14:28 -0500

Dirk Thomas gravatar image

The --extend option is define within catkin which generates the setup files (not catkin_tools).

The chaining of workspaces basically works as follows:

  • If you build a workspace A without sourcing any setup file before the workspace A is not chained (so it can't use anything from other workspaces)
  • When you source the setup file of workspace A and then build a workspace B that workspace B will overlay the sourced workspace A).
  • When you then source the setup file of workspace B and then build a workspace C that workspace C will overlay the sourced workspace B and the workspace A).

What you can commonly not do is source two setup files. At least you won't get the result you might expect. Lets consider the following example:

  • Workspace A was built without sourcing anything else before.
  • Workspace B was built without sourcing anything else before.
  • When sourcing the setup file of workspace A and then of workspace B the resulting environment will contain only the stuff from B. The reason is that the setup files will try their best to undo the environment changes from workspace A when sourcing the setup file of workspace B.
  • Their are two options to get a "merged" environment:

    • Rebuild one of the workspaces with the other workspace sourced to chain them.
    • Source the second setup file with the option --extend.

After describing all this for ROS 1 finally getting to the difference in ROS 2:

The setup files in ROS 2 / ament do not contain any logic to undo changes of previously sourced workspaces. Simply because that logic is very fragile and likely to be incomplete in non-trivial cases. As such they also don't provide the --extend logic since you can simply source two setup files from independent workspaces and the result will be an environment containing both.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2019-01-14 19:04:33 -0500

Seen: 457 times

Last updated: Jan 15 '19