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

[Jochen Sprickerhof]

Hi Daniele,

* Daniele E. Domenichelli  [2016-08-18 19:25]:
> Done. Also ros-control-msgs and ros-move-base contain action files, I
> moved them as well inside the msgs package.

Awesome, thanks a lot! I will start uploading the new versions now. Note
that they have to go through the new queue, so it will take some time
before they will hit unstable.

> I just realized that I named the package "ros-std-srvs" but perhaps it
> should have been ros-std-srvs-msgs, what do you think?

I think it's fine, I added it to ros-metapackages as well.

> I don't know if there are others, but I couldn't find any other here
> https://anonscm.debian.org/cgit/debian-science/packages/ros and using
> apt-file, etc.

No, they are all listed there.

> I added each package in the same meta-package as the relative -dev
> (sorry, I pushed by mistake one broken commit, fixed in the following
> one, I don't know if you want to use "gbp dch" for this).

No problem, I edit them.

> The "libcontrol-msgs-dev" package was not in any of them, so I didn't
> add it.

ros-control-msgs is not released into Debian yet.

Cheers Jochen


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

Hello Jochen,


On 2016-08-16 20:08, Jochen Sprickerhof wrote:

/usr/share/sensor_msgs contains srv/ as well. I would propose to put it
into the msg package as well. Same hold true for some other packages.


Done. Also ros-control-msgs and ros-move-base contain action files, I
moved them as well inside the msgs package.


I updated these repositories and added the following new packages:

 * ros-common-msgs
- ros-actionlib-msgs
- ros-diagnostic-msgs
- ros-geometry-msgs
- ros-nav-msgs
- ros-sensor-msgs
- ros-shape-msgs
- ros-stereo-msgs
- ros-trajectory-msgs
- ros-visualization-msgs
 * ros-control-msgs
- ros-control-msgs
 * ros-geometry-experimental
- ros-tf2-msgs
 * ros-navigation-msgs
- ros-map-msgs
- ros-move-base-msgs
 * ros-pcl-msgs
- ros-pcl-msgs
 * ros-ros-comm
- ros-roscpp-msgs
- ros-topic-tools-msgs
 * ros-ros-comm-msgs
- ros-rosgraph-msgs
- ros-std-srvs*
 * ros-std-msgs
- ros-std-msgs

I just realized that I named the package "ros-std-srvs" but perhaps it
should have been ros-std-srvs-msgs, what do you think?

I don't know if there are others, but I couldn't find any other here
https://anonscm.debian.org/cgit/debian-science/packages/ros and using
apt-file, etc.

I added each package in the same meta-package as the relative -dev
(sorry, I pushed by mistake one broken commit, fixed in the following
one, I don't know if you want to use "gbp dch" for this).

The "libcontrol-msgs-dev" package was not in any of them, so I didn't
add it.

Also I don't know if you want to change the name of the ros-std-srvs
package so I didn't add that as well.

Cheers,
 Daniele

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

[Jochen Sprickerhof]

* Daniele E. Domenichelli  [2016-08-16 17:41]:
> Is there a discussion upstream on some mailing list or some issue
> tracker? Any suggestion about how to implement it?

http://discourse.ros.org/ or
https://github.com/ros/catkin/issues

> Also btw, I'm working on packaging YARP, it would be great to have it in
> the debianscience/robotics packages...

Yeah, sounds awesome :).

> I'm attaching the patch for ros-common-msgs, I'm not sure about the
> dependecies here. For example libactionlib-msgs-dev depends on
> libstd-msgs-dev, probably because the messages in this library use
> messages defined in ros-std-msgs. Therefore I added a dependency to
> ros-std-msgs in the ros-actionlib-msgs package, since, in order to
> generate bindings for some other language, this package must be
> available. Anyway it is not strictly required as for a library that will
> not work if the other is missing, so perhaps it should be recommended
> instead? What do you think?

I think depends is fine for now. We can still rethink it, if someone has
different needs ;).

> If this is ok for you, I will apply the same kind of patch to all the
> other message packages and push the commit straight to the repositories,
> otherwise let me know, and I will post the patches here one by one.

Except the comment below, feel free to directly push your changes :).

> diff --git a/debian/ros-sensor-msgs.install b/debian/ros-sensor-msgs.install
> new file mode 100644
> index 000..8be5479
> --- /dev/null
> +++ b/debian/ros-sensor-msgs.install
> @@ -0,0 +1 @@
> +usr/share/sensor_msgs/msg

/usr/share/sensor_msgs contains srv/ as well. I would propose to put it
into the msg package as well. Same hold true for some other packages.

Cheers Jochen


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

On 2016-08-11 23:13, Jochen Sprickerhof wrote:

But perhaps this is something that should be fixed upstream (i.e. in
catkin)? I'm not sure if it is still in development or if it is frozen
though, since for ROS2 they are using a different tool.


Yes, talking to upstream about it is a good idea and judging from the
git repo it is quite active:

https://github.com/ros/catkin/commits/kinetic-devel


Is there a discussion upstream on some mailing list or some issue
tracker? Any suggestion about how to implement it?




Btw. would you be interested to
regularly work on the packages? There is still a lot that needs to be
done, so we would be glad to have an other helping (and thinking ;) )
hand. You can find the current process here:

https://wiki.debian.org/DebianScience/Robotics/ROS


I'm happy to help with the message packages, I'm not sure about the 
other

packages, since I'm not a big ROS user (I use it mostly to test the
compatibility with YARP), but if I can help I'll be happy to.
Also btw, I'm working on packaging YARP, it would be great to have it in
the debianscience/robotics packages...



I'm attaching the patch for ros-common-msgs, I'm not sure about the
dependecies here. For example libactionlib-msgs-dev depends on
libstd-msgs-dev, probably because the messages in this library use
messages defined in ros-std-msgs. Therefore I added a dependency to
ros-std-msgs in the ros-actionlib-msgs package, since, in order to
generate bindings for some other language, this package must be
available. Anyway it is not strictly required as for a library that will
not work if the other is missing, so perhaps it should be recommended
instead? What do you think?

If this is ok for you, I will apply the same kind of patch to all the
other message packages and push the commit straight to the repositories,
otherwise let me know, and I will post the patches here one by one.


Cheers,
 Daniele
From b0e279f68d68fb77a27489400f4e62024b94fb4c Mon Sep 17 00:00:00 2001
From: "Daniele E. Domenichelli" 
Date: Tue, 16 Aug 2016 17:13:49 +0200
Subject: [PATCH] Move message definitions in separate packages.

---
 debian/control   | 110 +++
 debian/libactionlib-msgs-dev.install |   3 +-
 debian/libdiagnostic-msgs-dev.install|   3 +-
 debian/libgeometry-msgs-dev.install  |   3 +-
 debian/libnav-msgs-dev.install   |   3 +-
 debian/libsensor-msgs-dev.install|   3 +-
 debian/libshape-msgs-dev.install |   3 +-
 debian/libstereo-msgs-dev.install|   3 +-
 debian/libtrajectory-msgs-dev.install|   3 +-
 debian/libvisualization-msgs-dev.install |   3 +-
 debian/ros-actionlib-msgs.install|   1 +
 debian/ros-diagnostic-msgs.install   |   1 +
 debian/ros-geometry-msgs.install |   1 +
 debian/ros-nav-msgs.install  |   1 +
 debian/ros-sensor-msgs.install   |   1 +
 debian/ros-shape-msgs.install|   1 +
 debian/ros-stereo-msgs.install   |   1 +
 debian/ros-trajectory-msgs.install   |   1 +
 debian/ros-visualization-msgs.install|   1 +
 19 files changed, 137 insertions(+), 9 deletions(-)
 create mode 100644 debian/ros-actionlib-msgs.install
 create mode 100644 debian/ros-diagnostic-msgs.install
 create mode 100644 debian/ros-geometry-msgs.install
 create mode 100644 debian/ros-nav-msgs.install
 create mode 100644 debian/ros-sensor-msgs.install
 create mode 100644 debian/ros-shape-msgs.install
 create mode 100644 debian/ros-stereo-msgs.install
 create mode 100644 debian/ros-trajectory-msgs.install
 create mode 100644 debian/ros-visualization-msgs.install

diff --git a/debian/control b/debian/control
index 1f1cdf6..9c5ee6a 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,18 @@ Homepage: https://github.com/ros/common_msgs
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/ros/ros-common-msgs.git
 Vcs-Git: https://anonscm.debian.org/cgit/debian-science/packages/ros/ros-common-msgs.git
 
+Package: ros-actionlib-msgs
+Section: devel
+Architecture: all
+Depends: ${misc:Depends}, ros-std-msgs
+Description: Messages relating to Robot OS actionlib, definitions
+ This package is part of Robot OS (ROS), and contains the common
+ messages to interact with an action server and an action client.  For
+ full documentation of the actionlib API see the
+ http://wiki.ros.org/actionlib package.
+ .
+ This package contains the message definitions.
+
 Package: libactionlib-msgs-dev
 Section: libdevel
 Architecture: all
@@ -48,6 +60,20 @@ Description: Messages relating to Robot OS actionlib, LISP interface
  .
  This package contains the generated LISP library.
 
+Package: ros-diagnostic-msgs
+Section: devel
+Architecture: all
+Depends: ${misc:Depends}, ros-std-msgs
+Description: Messages relating to Robot OS diagnostic, definitions
+ This package is part of Robot OS (ROS), and contains the messages
+ which provide the standardized interface for the 

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

[Jochen Sprickerhof]

* Daniele E. Domenichelli  [2016-08-11 18:57]:
> Another reason why I would like a cmake config file installed with the
> package and not a Findstd_msgs.cmake file in my projects is to be able
> to check the version... At some point, perhaps, some message might be
> added, removed, or modified, and I would like to be able to pass the
> version to find_package and be sure that the version found is compatible
> with the one I require.
> But perhaps this is something that should be fixed upstream (i.e. in
> catkin)? I'm not sure if it is still in development or if it is frozen
> though, since for ROS2 they are using a different tool.

Yes, talking to upstream about it is a good idea and judging from the
git repo it is quite active:

https://github.com/ros/catkin/commits/kinetic-devel

> From the tests I made, I couldn't find any difference, the messages are
> probably used only to produce the bindings, but they are useless for ROS
> user after.
> So perhaps "Recommends" is too much. Maybe "Suggests"? Or maybe
> nothing...

I think people doing development in ROS will use the available meta
packages and get them automatically.

> Perfect, I'll work on that as soon as possible then, but I'll be on
> holiday until Tuesday though, so it will have to wait for a few days...

No problem, enjoy your vocation. Btw. would you be interested to
regularly work on the packages? There is still a lot that needs to be
done, so we would be glad to have an other helping (and thinking ;) )
hand. You can find the current process here:

https://wiki.debian.org/DebianScience/Robotics/ROS

Cheers Jochen


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

On 2016-08-11 12:29, Jochen Sprickerhof wrote:

Where is ${std_msgs_DATAROOTDIR} defined?


Nowhere at the moment, I was hoping to find it in some CMake config
file. ;)



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



Another reason why I would like a cmake config file installed with the
package and not a Findstd_msgs.cmake file in my projects is to be able
to check the version... At some point, perhaps, some message might be
added, removed, or modified, and I would like to be able to pass the
version to find_package and be sure that the version found is compatible
with the one I require.
But perhaps this is something that should be fixed upstream (i.e. in
catkin)? I'm not sure if it is still in development or if it is frozen
though, since for ROS2 they are using a different tool.



> 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?


Ok.



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)?


From the tests I made, I couldn't find any difference, the messages are
probably used only to produce the bindings, but they are useless for ROS
user after.
So perhaps "Recommends" is too much. Maybe "Suggests"? Or maybe
nothing...




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.


I cannot think of any at the moment, so let's not add it.
Eventually if we can think about a good reason, it can be added in the
future.




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).


Perfect, I'll work on that as soon as possible then, but I'll be on
holiday until Tuesday though, so it will have to wait for a few days...



Cheers,
 Daniele

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

[Jochen Sprickerhof]

* Daniele E. Domenichelli  [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


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

Hello Jochen,


On 2016-08-10 22:06, Jochen Sprickerhof wrote:

It would be useful to be able to do something similar anyway, perhaps
find_package(std_msgs COMPONENTS messages), but I think the CMake 
files

are generated and are supposed to be used with catkin and I don't know
much about it. Suggestions?

Perhaps I'll just add a Findstd_msgs.cmake to my projects...


(old comment)
Why would you use cmake to find the messages? I would propose to just
keep them in the canonical directory. Otherwise +1.


I'll try to explain it better...

We have a tool that generates bindings for ROS messages that can be used
with YARP. We don't generate (yet?) libraries for message bindings, and
this means that every module will generate the bindings for the messages
that it actually uses. We use plain CMake (i.e. no catkin involved).

So a "module" project that uses YARP and want to be able to
publish/subscribe ROS messages (for example std_msgs/String and
std_msgs/ColorRGBA.msg), will have a CMakeLists.txt that is similar to
this:


   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)


   add_executable(foo foo.cpp ${GENERATED_SRCS})
   target_link_libraries(${YARP_LIBRARIES})


Neither ROS, nor catkin is involved here, just the msgs files...




Why not use $CMAKE_INSTALL_DATAROOTDIR or
$CATKIN_GLOBAL_SHARE_DESTINATION? I don't think we need an extra
find*.cmake.



$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.




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. Perhaps also the libstd-msgs-dev package should recommend it?
Perhaps should we add an extra meta package ros-core-msgs?



Actually I'm already registered and member of the debian-science 
group,

I'm not sure of which permissions I have on the repositories though.
perhaps when the patch is ready I can try pushing it...


That's great, you should be able to push this, feel free do go ahead 
:).


It worked! :)
Should I go on and do the same for the other message packages?



Cheers,
 Daniele

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

[Jochen Sprickerhof]

Hi Daniele,

* Daniele E. Domenichelli  [2016-08-10 15:19]:
> Thanks! I replied to the comments on github, anyway I'm reporting the
> everything here:

Great, let's move it all over here.

> It would be useful to be able to do something similar anyway, perhaps
> find_package(std_msgs COMPONENTS messages), but I think the CMake files
> are generated and are supposed to be used with catkin and I don't know
> much about it. Suggestions?
> 
> Perhaps I'll just add a Findstd_msgs.cmake to my projects...

(old comment)
Why would you use cmake to find the messages? I would propose to just
keep them in the canonical directory. Otherwise +1.

* Daniele E. Domenichelli  [2016-08-10 08:45]:
> In my CMake project, I would like to do something like this:
> 
> ```cmake
>  find_package(std_msgs REQUIRED)
>  generate_bindings("${std_msgs_MSG_DIR}/std_msgs/String.msg")
> ```

Why not use $CMAKE_INSTALL_DATAROOTDIR or
$CATKIN_GLOBAL_SHARE_DESTINATION? I don't think we need an extra
find*.cmake.

> Attached you will find the 2nd version of the patch.
> I moved the CMake files and the package.xml files back to the original
> package, removed the dependencies, and reverted the changes to the
> changelog file.

Looking great from my side. 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?

> Actually I'm already registered and member of the debian-science group,
> I'm not sure of which permissions I have on the repositories though.
> perhaps when the patch is ready I can try pushing it...

That's great, you should be able to push this, feel free do go ahead :).

Cheers Jochen


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

On 2016-08-09 21:29, Jochen Sprickerhof wrote:

Hi Daniele,

* Daniele E. Domenichelli  [2016-08-09 20:03]:

I suppose this should be done to all the ros-*-msgs packages, right?


Yes :).


I already have a patch for ros-std-msgs, you can find it here:

https://github.com/drdanz/ros-std-msgs/commit/41dcc24cd3a654e612a33e16e5442bf276d861fe


I've added some comments.


Thanks! I replied to the comments on github, anyway I'm reporting the
everything here:




--- a/debian/changelog
+++ b/debian/changelog
[...]


You don't need to add this, git-buildpackage will take care of it.



Cool, I didn't know about this! I think this mean that I have to amend
the commit and add (Closes: #833383) to the commit log, right?



--- a/debian/control
+++ b/debian/control
[...]
-Depends: ${misc:Depends}, ros-message-runtime
+Depends: ${misc:Depends}, ros-message-runtime,
+ ros-std-msgs (= ${source:Version})


Why do they depend on it?



--- /dev/null
+++ b/debian/ros-std-msgs.install
@@ -0,0 +1 @@
+usr/share/std_msgs


I'm not sure here, it includes the cmake and package.xml file.
Shouldn't they be part of the libstd-msgs-dev?



I added the dependency for the CMake files, but perhaps it's just enough
to move the .msg files only and remove the dependency.

find_package(std_msgs) will fail anyway without ros-message-runtime, so
I should probably move them back.

It would be useful to be able to do something similar anyway, perhaps
find_package(std_msgs COMPONENTS messages), but I think the CMake files
are generated and are supposed to be used with catkin and I don't know
much about it. Suggestions?

Perhaps I'll just add a Findstd_msgs.cmake to my projects...





I would propose to attach the patch to this bug (by mail), so we can
discuss the details.


Attached you will find the 2nd version of the patch.
I moved the CMake files and the package.xml files back to the original
package, removed the dependencies, and reverted the changes to the
changelog file.




If you want, you can register to alioth.debian.org
and request membership to the debian-science group, so you get direct
commit access to our repos.



Actually I'm already registered and member of the debian-science group,
I'm not sure of which permissions I have on the repositories though.
perhaps when the patch is ready I can try pushing it...



Cheers,
 Daniele
From: "Daniele E. Domenichelli" 
Date: Wed, 10 Aug 2016 09:45:18 +0200
Subject: Move message definitions in ros-std-msgs package. (Closes #833383)

---
 debian/control | 11 +++
 debian/libstd-msgs-dev.install |  3 ++-
 debian/ros-std-msgs.install|  1 +
 3 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 debian/ros-std-msgs.install

diff --git a/debian/control b/debian/control
index 076e496..db63bfa 100644
--- a/debian/control
+++ b/debian/control
@@ -11,6 +11,17 @@ Homepage: http://wiki.ros.org/std_msgs
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=debian-science/packages/ros/ros-std-msgs.git
 Vcs-Git: git://anonscm.debian.org/debian-science/packages/ros/ros-std-msgs.git
 
+Package: ros-std-msgs
+Section: devel
+Architecture: all
+Depends: ${misc:Depends}
+Description: Message definitions for Standard Robot OS Messages
+ This package is part of Robot OS (ROS). It contains message
+ definitions for the ROS std_msgs library, which contains wrappers for
+ ROS primitive types, which are documented in the msg specification. It
+ also contains the Empty type, which is useful for sending an empty
+ signal.
+
 Package: libstd-msgs-dev
 Architecture: all
 Depends: ${misc:Depends}, ros-message-runtime
diff --git a/debian/libstd-msgs-dev.install b/debian/libstd-msgs-dev.install
index 83f650b..7d5df8e 100644
--- a/debian/libstd-msgs-dev.install
+++ b/debian/libstd-msgs-dev.install
@@ -1,3 +1,4 @@
 usr/include
-usr/share/std_msgs
+usr/share/std_msgs/cmake
+usr/share/std_msgs/package.xml
 usr/lib/*/pkgconfig/std_msgs.pc usr/lib/pkgconfig
diff --git a/debian/ros-std-msgs.install b/debian/ros-std-msgs.install
new file mode 100644
index 000..5bf1da8
--- /dev/null
+++ b/debian/ros-std-msgs.install
@@ -0,0 +1 @@
+usr/share/std_msgs/msg

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

[Jochen Sprickerhof]

Hi Daniele,

* Daniele E. Domenichelli  [2016-08-09 20:03]:
> I suppose this should be done to all the ros-*-msgs packages, right?

Yes :).

> I already have a patch for ros-std-msgs, you can find it here:
> 
> https://github.com/drdanz/ros-std-msgs/commit/41dcc24cd3a654e612a33e16e5442bf276d861fe

I've added some comments.

> (I'm not sure if this is the right way to send a patch, I hope the link
> to github is ok, please forgive me if it is not and let me know how I
> should send it)

I would propose to attach the patch to this bug (by mail), so we can
discuss the details. If you want, you can register to alioth.debian.org
and request membership to the debian-science group, so you get direct
commit access to our repos.

Cheers Jochen


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

Hello Jochen,

On 2016-08-05 10:28, Jochen Sprickerhof wrote:

So we move everything in /usr/share/std_msgs, right?

Package: ros-std-msgs
Section: devel

Something like that?


Sounds good to me.



Would you be interested in working on it?


Yes, I can work on it.
I suppose this should be done to all the ros-*-msgs packages, right?

I already have a patch for ros-std-msgs, you can find it here:

  
https://github.com/drdanz/ros-std-msgs/commit/41dcc24cd3a654e612a33e16e5442bf276d861fe


(I'm not sure if this is the right way to send a patch, I hope the link
to github is ok, please forgive me if it is not and let me know how I
should send it)


Cheers,
 Daniele

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

[Jochen Sprickerhof]

* ddomeniche...@drdanz.it  [2016-08-05 00:05]:
> These messages definition could be used to generate bindings for other 
> programming languages and/or frameworks.

Good point :).

> I'd like to have it in a separate package, with a very small number of 
> dependencies.
> In an ideal situation I'd like to call from CMake something like this:
> 
>  find_package(std_msgs REQUIRED)
>  generate_bindings("$std_msgs_MSG_DIR}/std_msgs/String.msg")

So we move everything in /usr/share/std_msgs, right?

Package: ros-std-msgs
Section: devel

Something like that?
Would you be interested in working on it?

Cheers Jochen


signature.asc
Description: PGP signature

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

[ddomenichelli]

‎Hello Jochen,

> Interesting point, what would be the use case?

These messages definition could be used to generate bindings for other 
programming languages and/or frameworks.
In my specific case, in YARP (another middleware for robotics similar to ROS) 
we have a way to publish/subscribe to ROS publisher and subscribers, and we 
have a tool to generate bindings for ROS messages that do not use ROS libraries 
using the message definition.
We have a very small number of dependencies, and we cannot use the -dev package 
because it depends on many other packages, therefore at the moment we are 
forced to include in each module a copy of the definition of the messages used, 
but that's obviously redundant, and it would be a lot better if they were 
installed somewhere on the system.

> Should we put it into an extra package or in the library?

I'd like to have it in a separate package, with a very small number of 
dependencies.
In an ideal situation I'd like to call from CMake something like this:

 find_package(std_msgs REQUIRED)
 generate_bindings("$std_msgs_MSG_DIR}/std_msgs/String.msg")


Cheers,
 Daniele

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

[Jochen Sprickerhof]

Hi Daniele,

* Daniele E. Domenichelli  [2016-08-03 19:35]:
> It would be very useful to be able to install the message definitions without
> installing the whole libstd-msgs-dev package that depends on many other
> packages.

Interesting point, what would be the use case?
Should we put it into an extra package or in the library?
My idea was that it's only useful for developers and they would have the
-dev packages installed anyhow.

Cheers Jochen


signature.asc
Description: PGP signature

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

[Daniele E. Domenichelli]

Source: ros-std-msgs
Severity: wishlist

It would be very useful to be able to install the message definitions without
installing the whole libstd-msgs-dev package that depends on many other
packages.
The same applies to all the other ros messages packages.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable'), (300, 'unstable'), (150, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)