-
Notifications
You must be signed in to change notification settings - Fork 48
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
Support and prefer exported targets from rmw implementations #201
Conversation
Signed-off-by: Shane Loretz <sloretz@osrfoundation.org>
The single rmw implementation case and multi rmw implementation cases both need to be tested, so I'll do CI in stages as long as it looks positive. First: Does it work with the single RMW implementation CI (build: |
Signed-off-by: Shane Loretz <sloretz@osrfoundation.org>
Retrying CI with a repos file with the two linked PRs: https://gist.githubusercontent.com/sloretz/26349bc77eb0931f8dbff9d3b4539d2d/raw/353b596d04cee3d2511ce7734c77a39fb87ddee2/ros2.repos CI (build: EDIT: Failing due to test arguments not ignoring unbuilt packages, still, building all the way is promising |
CI again Single RMW implementation case witn rmw_cyclonedds
Jobs |
Hm, Windows CI is cranky, failing to load certain DLLs. I'm not sure if that is related to the change, or maybe to the set of build/test flags? Either way it probably needs to be looked into. |
It's very interesting that Possibly related to ros2/launch_ros#288 ? |
I setup a windows VM and ran the same arguments, and I can't reproduce it. I'll try another CI run to see if it's a flaky issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I only have a minor comment.
rmw_implementation/CMakeLists.txt
Outdated
ament_index_cpp::ament_index_cpp | ||
rcpputils::rcpputils | ||
rcutils::rcutils | ||
Threads::Threads) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is Threads
needed?
This library doesn't use threads.
If some dependency does need it, they should be exporting the link library correctly.
In my local testing I haven't found any issue with not adding Threads
here, but I might have tested something incorrectly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was added because fastrtps wasn't exporting the dependency correctly at some point, but AFAIS it's not needed anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed unnecessary dependency on Threads:Threads in 8f00520
Try as I might, I can't reproduce the Windows CI test failure locally on a windows VM. I'm going to apply Ivan's feedback and open up a mitigation in |
Another Windows run with ros2/launch#572 included |
Signed-off-by: Shane Loretz <sloretz@osrfoundation.org>
Yet another run after fixing ros2/launch#572 |
It's really strange that now there's no even a warning 😮 |
Something odd going on with the above CI jobs - lots of them don't have the parameters I set on the launcher. https://ci.ros2.org/job/ci_linux-aarch64/10524/parameters/ There might be a ros2/ci bug here. Investigating. |
Signed-off-by: Shane Loretz <sloretz@osrfoundation.org>
No CI bugs! Failing combined CI is due to tests having dependencies that they weren't target-linked against. Fixed in c03b44f |
Since c03b44f modifies code that's only enabled in the multi-RMW case, I think the green CI for the single RMW cases is still valid. I'll rerun the CI for the connext/cyclone/fastdds combinded jobs only: |
@Blast545 FYI this is an attempt to fix the CI issue from ros2/rmw_cyclonedds#357
Requires ros2/rmw_cyclonedds#360✔️Requires ros2/realtime_support#112✔️The package
rmw_implementation
appears to be the CMake interface between downstream libraries likercl
and the actual rmw implementations. It looks like when there are multiple rmw_implementations it will export a shared library that can load and switch between them, but when there is only one implementation it sets old-style standard CMake variables to the underlying implementation. Unfortunately, the latter expects the rmw implementation to set old-style CMake variables instead of modern CMake targets.This PR creates an
IMPORTED
targetrmw_implementation::rmw_implementation
and variablermw_implementation_TARGETS
that lets downstream packages like rcl depend on targets instead of old-style CMake variables. It also updates the logic to support, and prefer, modern CMake from the rmw implementations when available.I also replaced an out-of-place
CMAKE_THREAD_LIBS_INIT
with a dependency onThreads::Threads
on the shared library.