Export typesupport library in a separate cmake variable #453
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
|
hidmic
approved these changes
Apr 1, 2020
There was a problem hiding this comment.
LGTM, I see where you're going now. I'd like @dirk-thomas to take a look at this as well though.
dirk-thomas
approved these changes
Apr 1, 2020
|
delete-merged-branch
bot
deleted the
ivanpauno/export-typesupport-separately
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
Same as ros2/rosidl_typesupport_connext@56e609d.
See #284 and ros2/ros2#437 for further reference.
Long story
Generated interfaces' typesupports shouldn't be exported in
${PROJECT_NAME}_LIBRARIEScmake variable.rosidl_typesupport_connext_*is already handling this correctly.These generated typesupport libraries are only needed when linking by:
target_link_librariesneeded to consider the new variable.rosidl_typesupport_corrosidl_typesupport_cppwill need to link against the specific typesupport generated here. Preexisting code was already considering the existence of the variable used here https://github.com/ros2/rosidl_typesupport/blob/4847322f6a03e5a2ec5cf0498ec8d93d0be8f7b4/rosidl_typesupport_c/cmake/rosidl_typesupport_c_generate_interfaces.cmake#L119-L120, so there's nothing else to fix. In case multiple typesupports are available, POCO is used and there's no need to link against the libraries generated here.Why now?
When testing ros2/rmw_fastrtps#312, I find two new regressions in the
os Xjob https://ci.ros2.org/job/ci_osx/7989/:Those tests where failing when loading
librmw_dds_common_interfaces__rosidl_typesupport_introspection_cpp.sobecauselibrosidl_typesupport_introspection_c.dylibwasn't found.That library isn't needed at all by the package, and shouldn't be linked against in the first place.
This PR together with ros2/rmw_fastrtps@8b6f556 fix that bug, and I'm only linking against the typesupport I need now.