Catkin and distribution targets

[gergondet]

Hi all,

I'd like to discuss an issue (and ideally a solution to that issue) that I encountered while working with several projects that use jrl-cmakemodules (and more specifically the SETUP_PROJECT macro) and trying to build them in a catkin environment.

When calling the SETUP_PROJECT() macro, a bunch of other macros are called, in particular, the _SETUP_PROJECT_DIST(), DISTCHECK_SETUP() and RELEASE_SETUP() macros. These macros create targets that are most useful for packaging purposes (i.e. dist* targets and release target).

Now, the catch is that if you have multiple projects within your catkin workspace that use this macro then your build will fail at the configuration step when invoking catkin_make because it's trying to create multiple targets that share the same name which is illegal.

One work-around is to use catkin_make_isolated (see http://www.ros.org/reps/rep-0134.html). Using the appropriate option it can be invoked in a way that the output mimics the results of catkin_make but the build still occur in an isolated way for each package. However, it would be nice to be able to invoke catkin_make directly without worries.

I see two possible solutions to this problem but there may be more (and better):

1. Change the dist* and release target names to something that depends on the project name (e.g. release-${PROJECT_NAME}). This requires very little effort but will break every scripts that are used to generate packages (e.g. jrl-umi3218/jrl-travis)
2. Don't generate these targets unless explicitly made to. This way, we require an additional arguments to have these targets generated. This makes the transition much easier for scripts that package the software (i.e. just use an additional argument when invoking cmake)

Any other solution that does not break anything would be most welcome. Alternatively it might just not make much sense to keep using SETUP_PROJECT within a catkin project.

A few more notes on the matter:

• afaik, it's not possible to redefine an existing target or even test for its existence
• it is also not possible to ignore those errors and continue onto the Makefile generation by cmake

Best,

[olivier-stasse]

Hi Pierre,
This is an interesting question.
I do believe that the correct policy is to acknowledge the fact that library implementing algorithms should be decoupled from the middleware where still using jrl-cmakemodules seems to make sense.
Whereas middleware components encapsulating the algorithms for ROS exposure should follow the catkin way.
However I am not in favor in a general in switching all the libraries to ROS.

[gergondet]

Hi Olivier,

Thanks for your reply. If I get your meaning correctly, you suggest that we drop the use of jrl-cmakemodules in middleware components or at least limit it (i.e. no SETUP_PROJECT) in middleware components which is the case of the two packages that are actually posing me a problem (robot_capsule_urdf and dynamic_graph_bridge to name them). That's also fine by me.

The question that remains concerns the usefulness of these targets for these particular packages then and that should probably be addressed there.

[olivier-stasse]

Probably the real point is to understand how people are building this target. Here at LAAS they are at least 3 ways that people are building these packages: install-sot.sh, robotpkg and, something I never tried which is a Makefile installing a set of packages. I am fine to modify install-sot.sh to reflect the changes. robotpkg is handled by Aurelie. The later option is handled by Florent Lamiraux. I will ask him, but he is currently in holidays. Do you see any other person ?

I would like to specify that I considered this solution only for developers. robotpkg aims at providing binary packages for released version, and this way ease the installation process for not specialist user. We are on the verge on finishing a version with Romeo.

[gergondet]

I only know of people using install-sot.sh (that should be adapted to go the catkin road anyway) so I'm relying on feedback from people at LAAS regarding the other two options.

[thomas-moulard]

If your project is using jrl-cmakemodules, it should not be built using the catkin macros.

The good thing with recent ROS distributions is that they do not rely anymore on custom installation principles. You can just install a "normal" package into the same prefix and it should work out of the box.
ROS packages can now be detected using pkg-config so catkin has little interest for our usual use case. If you miss a feature, implementing it in jrl-cmakemodules without relying on catkin makes sense to me.

[jcarpent]

This issue has been solved recently by #214.