Revision history - ROS Answers: Open Source Q&A Forum

This works fine with Catkin, just source /opt/ros/<rosdistro>/setup.sh, and run catkin_make_isolated --install --install-space /opt/ros/<rosdistro>.

So I assume multiple snaps installing the same file (as long as it is identical) is ok? (I am just asking because e.g. for Debian packages that is not the case.)

The setup.sh and local_setup.sh is customized for the given workspace, and the one in/opt/ros/<rosdistro>` is far different, and overwriting the system one with the workspace's of course doesn't work.

Can you please describe how they are different and if you are referring to the ones generated by colcon or by ament_cmake? (A comment line at the top of the files should clarify which template they have been expanded from.)

It looks like things work with colcon build --merge-install as long as I don't install the setup.sh and local_setup.sh generated for the workspace

What is the problem with these setup files? They shouldn't contain any different logic.

Is there a way to request that these files aren't generated/installed?

Not at the moment. Maybe a new command line option to make this line optional would help in that case (https://github.com/colcon/colcon-core/blob/839832f5dd079b0832bccd3f5778695163fe06f0/colcon_core/verb/build.py#L137) but I am not yet sure if that is really necessary...

This works fine with Catkin, just source /opt/ros/<rosdistro>/setup.sh, and run catkin_make_isolated --install --install-space /opt/ros/<rosdistro>.

So I assume multiple snaps installing the same file (as long as it is identical) is ok? (I am just asking because e.g. for Debian packages that is not the case.)

The setup.sh and local_setup.sh is customized for the given workspace, and the one in/opt/ros/<rosdistro>` is far different, and overwriting the system one with the workspace's of course doesn't work.

Can you please describe how they are different and if you are referring to the ones generated by colcon or by ament_cmake? (A comment line at the top of the files should clarify which template they have been expanded from.)

It looks like things work with colcon build --merge-install as long as I don't install the setup.sh and local_setup.sh generated for the workspace

What is the problem with these setup files? They shouldn't contain any different logic.

Is there a way to request that these files aren't generated/installed?

Not at the moment. Maybe a new command line option to make this line optional would help in that case (https://github.com/colcon/colcon-core/blob/839832f5dd079b0832bccd3f5778695163fe06f0/colcon_core/verb/build.py#L137) but I am not yet sure if that is really necessary...

Update:

The version installed by the OR debs is from ament, the version installed in the workspace is from colcon

Ok, as far as I understand you are using two workspaces: * the underlay in /opt/ros/crystal provided by Debian packages * the overlay (in the form of a snap) somewhere else which is supposed to depend on the underlay (so it was built with colcon and the underlay being sourced before)

And the problem is that when sourcing the setup.sh from the overlay workspace that you don't get anything from the underlay. Right?

This works fine with Catkin, just source /opt/ros/<rosdistro>/setup.sh, and run catkin_make_isolated --install --install-space /opt/ros/<rosdistro>.

So I assume multiple snaps installing the same file (as long as it is identical) is ok? (I am just asking because e.g. for Debian packages that is not the case.)

The setup.sh and local_setup.sh is customized for the given workspace, and the one in/opt/ros/<rosdistro>` is far different, and overwriting the system one with the workspace's of course doesn't work.

Can you please describe how they are different and if you are referring to the ones generated by colcon or by ament_cmake? (A comment line at the top of the files should clarify which template they have been expanded from.)

It looks like things work with colcon build --merge-install as long as I don't install the setup.sh and local_setup.sh generated for the workspace

What is the problem with these setup files? They shouldn't contain any different logic.

Is there a way to request that these files aren't generated/installed?

Not at the moment. Maybe a new command line option to make this line optional would help in that case (https://github.com/colcon/colcon-core/blob/839832f5dd079b0832bccd3f5778695163fe06f0/colcon_core/verb/build.py#L137) but I am not yet sure if that is really necessary...

~~Update:~~Update 1:

The version installed by the OR debs is from ament, the version installed in the workspace is from colcon

Ok, as far as I understand you are using two workspaces: * the underlay in /opt/ros/crystal provided by Debian packages * the overlay (in the form of a snap) somewhere else which is supposed to depend on the underlay (so it was built with colcon and the underlay being sourced before)

And the problem is that when sourcing the setup.sh from the overlay workspace that you don't get anything from the underlay. Right?

Update 2:

There are two ways to do that: install the overlay into another directory and keep it as a separate workspace and chain them in production, or install the overlay directory INTO the underlay so that in production there is only one workspace. The latter is the path we took for Catkin, and I'm attempting to do the same for Colcon. How are you handling this in the Debian packaging of Colcon components to work alongside the Ament ones?

The short answer: we don't. The Debian packages are built just using dpkg-buildpackage which invoked CMake which uses the logic of ament_cmake to generate the setup files (only for one of the Debian packages in order to not conflict). Any workspace built ontop by the user is currently in a separate workspace. And based on this conversation I don't think it will work to install the colcon workspace into the same workspace as the not-with-colcon installed packages.

That might be something we should consider and see if we can make this work (since it did work with ROS 1 and some users might be tempted to install newer versions of self built packages into /opt).

but then it started working for me like magic.

I still think there might be a bug in our current Debian packages though. When installing them and building a workspace with colcon ontop sourcing the resulting setup.sh file in the overlay doesn't give us the environment from the underlay which it is supposed to. In comparison when building an underlay with colcon and then an overlay with colcon the resulting setup file in the overlay will make sure to also source the underlay which was sources at build time of the overlay... (and right on time the following ticket is describing this problem: https://github.com/ros2/ros2/issues/653)

Revision history [back]