search

ros / genmsg

Standalone Python library for generating ROS message and service data structures for various languages
http://wiki.ros.org/genmsg
29 stars 74 forks source link

Feature to specify namespace of generated type of .msg/.srv? #93

Open kohei306 opened 4 years ago

kohei306 commented 4 years ago

It would be great if we can have flexibility to specify namespace for the generated message/service type. This helps not to break old recording after refactoring package structure and changing package name or separate it out to new package (This means name space changes).

dirk-thomas commented 4 years ago

Since the already released ROS distro Noetic is planned to be the last ROS 1 distribution there is no plan to implement new features like this. The straight forward workaround for your use case seems to be to keep the previous package name around.

kohei306 commented 4 years ago

Since the already released ROS distro Noetic is planned to be the last ROS 1 distribution there is no plan to implement new features like this. The straight forward workaround for your use case seems to be to keep the previous package name around.

I have made PRs for genmsg & gencpp.

https://github.com/ros/genmsg/pull/94 https://github.com/ros/gencpp/pull/50

dirk-thomas commented 4 years ago

I still don't think that this is a change we want to land in an already released distro. Also it opens the door to colliding files coming from different Debian packages.

Anyway the new maintainer of this repo @mjcarroll might want to comment on this.

Eddylib commented 4 years ago

It would be greate if the namespace can be inferenced by the structure of message defination dir. for example: directory structure

PackageA
    |---msg
         |---dir1
                |---message1.msg
         |---dir2
                |---message2.msg

output files: devel/include/PackageA/dir1/message1.msg devel/include/PackageA/dir2/message2.msg

usercode:

#include <PackageA/dir1/message1.h>
#include <PackageA/dir2/message2.h>
using PackageA::dir1::message1;
using PackageA::dir2::message2;

It will be great for integrate common messages into one package to reduce cycle dependence without corrupting the original structure of project.