search

ros2 / rosidl_typesupport

Packages which provide the typesupport for ROS messages and services
Apache License 2.0
13 stars 34 forks source link

Poco is no longer optional -- can it be? #53

Closed theseankelly closed 4 years ago

theseankelly commented 4 years ago

I'm working on porting the ros2_dotnet project to Crystal and Dashing.

A big motivation behind this project is running within a Universal Windows Platform (UWP) app container for devices like HoloLens or Windows IoT devices. In this context, Poco is not supported. In Bouncy and Crystal this is worked around by using a custom repos file which does not include poco_vendor, and by ensuring there's only a single typesupport available at build time (default in Bouncy; in Crystal one of the two Fast-RTPS typesupports must be skipped/ignored).

I've discovered this workaround is broken by @ivanpauno's PR (#46) which passes Poco into ament_target_dependencies.

Before I go and create a PR to 'fix' this, I wanted to get feedback from the maintainers as to whether building without Poco is a supported scenario moving forward, or whether perhaps there's a more correct way to achieve my goal to avoid the need for Poco/runtime typesupport selection.

dirk-thomas commented 4 years ago

As long as you don't need the dynamic dispatch provided by Poco (with a single RMW / single typesupport) you should be able to avoid the dependency. At least that was the original design idea. So any PR to restore that would be very welcome.