Closed tfoote closed 3 months ago
Would it be acceptable if these packages generated documentation for the msgs that was simply a copy of the msg file, with no parsing? That's how I did it in my earlier iteration.
Hmmm, no response, so I guess I'll just do this in a PR.
I could never figure out a non-tacky way of generating cross references to msg and srv files, which would be useful. But just showing the definitions as text files would be better than nothing.
Would it be acceptable if these packages generated documentation for the msgs that was simply a copy of the msg file, with no parsing? That's how I did it in my earlier iteration.
I think this is a good start.
In the long run, it would be great to also generate documentation for code generated by the various rosidl_generators
but this is non-trivial since we do not build the packages before running rosdoc2
.
My experience is that just showing the text works pretty well. You can see an example at https://rosdabbler.github.io/fqdemo/fqdemo_msgs/generated/msg/NumPwrData.html from my experimental version of rosdoc2.
The tricky part is trying to get cross references to msg classes to work. That experiment does it by declaring the message to be a python class that can be cross-referenced, but I'm not sure that is a good solution.
Anyway I'll propose a patch here once some of my other PRs clear.
A job like Rdoc_common_interfaces https://build.ros2.org/view/Rdoc/job/Rdoc__common_interfaces__ubuntu_jammy_amd64/
It is building sensor_msgs because they have an include folder and so doxygen is triggered. But all the other packages in that repository generate no content.
Example: https://build.ros2.org/view/Rdoc/job/Rdoc__common_interfaces__ubuntu_jammy_amd64/26/console