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
Force extension points to be registered in order #485
Force extension points to be registered in order #485
Conversation
rosidl_generator_c/cmake/rosidl_generator_c_generate_interfaces.cmake
Outdated
Show resolved
Hide resolved
...pesupport_introspection_c/cmake/rosidl_typesupport_introspection_c_generate_interfaces.cmake
Outdated
Show resolved
Hide resolved
a2e42d3
to
45d2326
Compare
While this is the right way to fix this I am certain that a runtime dependency on a generator package is undesired. @chapulina FYI - I couldn't find the meta ticket for that goal? |
rosidl_typesupport_introspection_c/rosidl_typesupport_introspection_c-extras.cmake.in
Outdated
Show resolved
Hide resolved
This introduces a "build tool export" dependency, which will require I can modify the PR, but I don't think that deleting the |
This is not how these dependency types work. This will result in a run dependency of the Debian package: https://github.com/ros-infrastructure/bloom/blob/9e81373b0e9be8d0e154dcc57ec8530b4ddc8ea5/bloom/generators/debian/generator.py#L317-L319 |
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
…pp in rosidl_typesupport_introspection_c/cpp Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
45d2326
to
ee57927
Compare
This doesn't introduce a runtime dependency on Applied suggestion here in ee57927. ros2/rosidl_typesupport#73 was introducing a runtime dependency on I think it would be better in the future to split these packages ( |
Same comments as ros2/rosidl_typesupport#73 (comment) and ros2/rosidl_typesupport#73 (comment). |
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Addressed in 7c1af45. |
This is needed after ament/ament_cmake#256.
Reverse inclusion of generated export targets files was a lucky choice in this case, as the extension points are executed in alphabetical order, and reverse alphabetical order was coincidental with the dependency order (a extreme coincidence 😄).
This PR ensures that extension points are registered in the correct order (and thus, executed in the correct order too).