-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing metadata #98
Comments
@bkueng sorry, I am not a maintainer of this repository anymore. |
@bkueng We would definitely consider a proposal to extend the msg format to be able to add richer documentation. This repository is entirely focused on ROS 1's implementation and with the final ROS 1 distro already released this is basically in maintenance only mode. This sort of proposal will want a much larger viewing audience as well as look forward for ROS 2. To that end I'd suggest that you propose this on ROS Discourse in the Next Generation ROS category: https://discourse.ros.org/c/ng-ros/25 and we can look at extending this for upcoming distributions. |
There's also some active ongoing work relating to this right now such as: ros2/rosidl#593 I'm going to close this in favor of continuing the discussion elsewhere either discourse or on rosidl |
I'm working on PX4, which used
genmsg
for code generation. Now the ask has come up to generate docs for .msg files, and I see ROS uses http://wiki.ros.org/rosdoc_lite, which parses the files independently, w/o any structure for metadata (comments in particular).This has obviously some drawbacks:
I'm suggesting to bring more structure to comments and parse them with
genmsg
, which then can be used to generate docs as well (single parser for all use-cases).I have not gone into the details, but I imagine something like this:
The tags are then parsed generically (no tag implies
@comment
tag), which then gets added as a dict togenmsg.MsgSpec
andgenmsg.Field
, so they can be used in a template.This should fit into the existing .msg file format structure.
Is there interest in extending files into that direction, and if so, are there any specific requirements you'd like to see?
@dirk-thomas @tfoote
The text was updated successfully, but these errors were encountered: