Skip to content
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

Change msg generation for nicer paths #19

Open
TimWhiting opened this issue Jan 19, 2021 · 3 comments
Open

Change msg generation for nicer paths #19

TimWhiting opened this issue Jan 19, 2021 · 3 comments
Labels
enhancement New feature or request low priority

Comments

@TimWhiting
Copy link
Collaborator

We can probably change the CMake to copy the message packages into the workspace, or in a global location.

Best practices? What should we do?
What global location? ~/.dart_msgs? $WORKSPACE/.dart_msgs I like the idea of a hidden folder by default.

Alternatives:
Use Dart's generation process along with annotations on imports to have messages generated only for the places they are used. Seems inefficient if you have multiple packages using the same messages.

Copy the packages into a subdirectory of the catkin package that is using them. Downside: Also duplicates the message package, and might cause package include conflicts when you have dart packages depending on each other but both importing the message package from different paths.

@TimWhiting
Copy link
Collaborator Author

@knuesel
Opinions?

@knuesel
Copy link
Contributor

knuesel commented Jan 22, 2021

Good question. A global directory such as ~/.dart_msgs feels a bit invasive and idiosyncratic to me... And what if a user needs several versions of the same message package? For example protoc (the protobuf tool) just generates files in a directory specified by the user. I find it non-invasive and quite flexible.

Copy the packages into a subdirectory of the catkin package that is using them.

Did you mean a subdirectory of the Dart package?

Actually I'm starting to like how it currently works :) I think for people working with a catkin workspace the current workflow makes sense. Users can choose themselves a canonical location for the package (either the default devel/share/gendart/ros or copy the files where they want) and use it in various Dart packages.

For the action test in test_dartros I did something a bit different, copying the message files directly in the application's lib/ without using the generated pubspec.yaml. Copying the files solved the following problems:

  • The src/test_dart directory is both a Dart package and a ROS package, so the Dart package generated in devel/share/gendart/ros is also called test_dart :-/
  • I wanted to include the generated files in the test_dart Git repository, so users don't need a ROS installation to compile the Dart application.

Ideas for improvements:

  1. Improve the generator to let the user choose the Dart package metadata (name, version...)

  2. Write a script to hide the catkin stuff for people who need ROS only to generate the messages. I'm thinking something that feels like protoc to the user:

    gendart --rosversion noetic -I/path/to/custom-ros-package /path/to/message-package /path/to/generated-files
    

    although it would be much heavier behind the scenes, e.g. using Docker to get the requested ROS version, mount the given paths and use catkin to generate the files.

What do you think?

@TimWhiting
Copy link
Collaborator Author

I like your suggestions. I'm fine with how it is right now as well, I end up copying it as part of the catkin build. I think a more configurable generation process would be good. However, I'm not sure many people would use dartros without also having some sort of manipulation / other package that would require catkin, so I'm thinking the protoc like option is very low priority.

I'm going to put this issue as low priority since we both find that it works well enough for our use cases.

@TimWhiting TimWhiting added enhancement New feature or request low priority labels Jan 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request low priority
Projects
None yet
Development

No branches or pull requests

2 participants