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
1

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

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

Seen: 201 times

Last updated: Jan 15 '19