Install environment hooks into a package-specific directory

[paulbovbel]

Required for colcon/colcon-ros#36, related to colcon/colcon-ros#35

[dirk-thomas]

I am not convinced this is the right way to address the problem. With the "slow" release cycle of catkin (it is released fairly infrequent due to the effort and impact) I would rather like to make sure that the approach is viable in the long term and in the various ways these scripts could be used.

• In the case of the setup files from catkin (global per ws) having all scripts in a single directory is good in order to find / source them efficiently. Hence this is the current state - optimized for that use case.

• In the case of the setup files colcon (per package) the scripts for a single package need to be identified. The need to read files and interpret their content in order to decide which other files to source seems to be sub optimal. If other tools want to reproduce the behavior they have to jump through the same hoops. For this use case it would be preferred if the scripts from a specific package would be installed in a package specific location (e.g. share/<pkgname>/...).

Both use cases should be supported efficiently. One possible approach would be to install these scripts in both locations - each optimized for one of the use cases. But I can't foresee yet if that will have other downsides down the road. Therefore I think this should be reconsidered with the bigger picture of general performance when sourcing setup file in mind.

[paulbovbel]

The need to read files and interpret their content in order to decide which other files to source seems to be sub optimal.

It makes sense to me that there should be some sort of record of which package installed what into a global workspace path, but I'm all for a more optimal solution.

One possible approach would be to install these scripts in both locations - each optimized for one of the use cases

This doesn't feel particularly more optimal that a manifest, but it is certainly simpler/more obvious. Perhaps the CATKIN_INSTALL_INTO_PREFIX_ROOT parameter should control whether the hooks are even installed into <install_base>/etc/catkin?

Therefore I think this should be reconsidered with the bigger picture of general performance when sourcing setup file in mind.

I'd be happy to collaborate on/contribute a solution that would be acceptable, but I don't have a good understanding of the bigger picture, and would appreciate some guidance. Would it make sense to open a separate ticket in colcon-ros for the issue of overall performance? At the very least I can start by contributing some metrics from sourcing large workspaces built by catkin-tools vs colcon.

[paulbovbel]

Adapted to install hooks into share/<pkgname>/profile.d

[dirk-thomas]

@ros/ros_team Please comment if you think is a good approach (or not).

[wjwwood]

Duplicating the files is not ideal, but I don't see a practical problem with it. It might be confusing to people who are trying to reverse engineer what catkin is doing, so more documentation might be in order, e.g. comments in the code where it is installed in two places, a marker file in the install space explaining what's going on, or documentation in the catkin documentation somewhere.

[dirk-thomas]

more documentation might be in order, e.g. comments in the code where it is installed in two places, a marker file in the install space explaining what's going on, or documentation in the catkin documentation somewhere.

84c6c95 adds information about the two install destinations to the docblock which will also appear in the generated docs.

[wjwwood]

Looks ok to me.

[dirk-thomas]

Thank you for the patch.

[dirk-thomas]

The CMake API docs have been regenerated in e086d89.

[paulbovbel]

Thanks for chasing this @dirk-thomas!

[dirk-thomas]

b1622e2 is a follow up to address warnings in the doc job.

[paulbovbel]

@dirk-thomas, can I please request a tagged release of this package which includes this PR?

[dirk-thomas]

It will likely be January until I get to do ROS 1 patch releases.