Bug#833383: ros-std-msgs: split headers and message definitions

[Jochen Sprickerhof]

* Daniele E. Domenichelli <ddomenichelli at drdanz.it> [2016-08-11 11:24]:
>    cmake_minimum_required(VERSION 2.8.9)
>    project(foo)
> 
>    find_package(YARP REQUIRED)
>    find_package(std_msgs REQUIRED)
> 
>    yarp_generate_bindings(GENERATED_SRCS
> "${std_msgs_DATAROOTDIR}/std_msgs/msg/String.msg"
> "${std_msgs_DATAROOTDIR}/std_msgs/msg/ColorRGBA.msg)

Where is ${std_msgs_DATAROOTDIR} defined?

> $CATKIN_GLOBAL_SHARE_DESTINATION will require catkin therefore I
> cannot use it.
> 
> $CMAKE_INSTALL_DATAROOTDIR is generated by GNUInstallDirs.cmake and
> it is by default "share" (relative) this means that if ROS packages are
> not installed in "/usr" (for example because they are installed from
> the ROS repository in "/opt") or if CMAKE_INSTALL_PREFIX of the module
> is not set to "/usr" (the default value is "/usr/local", therefore it
> will have to be set manually), the messages will not be found.

I see your point, but I'm nut sure about the right solution here. My
thinking is:

- If you want msg from the default path, $CMAKE_INSTALL_DATAROOTDIR
  should work (modulo the CMAKE_INSTALL_PREFIX).

- If you want them from /usr/local, you should set it manually.

- If you want it from the ROS packages in /opt, I would propose to
  include catkin and use $CATKIN_GLOBAL_SHARE_DESTINATION, as there
  could be multiple versions in /opt and sourcing setup.sh/catkin should
  give you the right one.

So maybe a cmake script would be useful after all :).

> > Maybe we will need some more dependencies
> > (or recommends) on this package, like for rosmsg for example and we
> > should add it to the ros-core-dev meta package. What do you think?
> 
> I agree.

Could you go ahead and add it?

> Perhaps also the libstd-msgs-dev package should recommend it?

Not sure here, does it change the usability of libstd-msgs-dev somehow
(didn't test)?

> Perhaps should we add an extra meta package ros-core-msgs?

Though about it as well, do you have a use case for it? Otherwise I
wouldn't do it.

> Should I go on and do the same for the other message packages?

Yes please :). Once we are fine with it, I will upload the new packages
(note that we have to go through the new queue).

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20160811/ccf18c80/attachment.sig>