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

Fix rosidl_generator_py assuming incorect library names #149

Merged
merged 1 commit into from Jan 11, 2022

Conversation

sloretz
Copy link
Contributor

@sloretz sloretz commented Dec 10, 2021

Requires ament/ament_cmake#371

rosidl_generator_py was assuming all interface packages being depended
upon call their interface generation target name "${PROJECT_NAME}", but
that's an incorrect assumption. The target name is a required argument
to rosidl_generate_interfaces(). This fixes it by exporting the python
library target using an existing CMake macro for that purpose called
rosidl_export_typesupport_targets() and ament_export_targets().

I works by adding a variable
"${PROJECT_NAME}_TARGETS__rosidl_generator_py" which is set when the
interface package is find_package()d. That variable contains the
targets generated by rosidl_generator_py so that downstream interface
packages can depend on it.

Since targets are being exported, a bug where build time include paths were marked PUBLIC also needed to be fixed.

I discovered this bug while working on ament/ament_cmake#365, and I need it fixed for ros2/rcl_interfaces#133

@sloretz sloretz self-assigned this Dec 10, 2021
@sloretz
Copy link
Contributor Author

sloretz commented Dec 10, 2021

CI (build: --packages-above-and-dependencies rosidl_generator_py test: --packages-above rosidl_generator_py)

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@sloretz
Copy link
Contributor Author

sloretz commented Dec 23, 2021

Trying Windows with repos file with this and ament/ament_cmake#371 Build Status

Re-run Build Status

re-re-run Build Status

re-re-re run Build Status

re-re-re-re run Build Status

re-re-re-re-re run Build Status

rosidl_generator_py was assuming all interface packages being depended
upon call their interface generation target name "${PROJECT_NAME}", but
that's an incorrect assumption. The target name is a required argument
to rosidl_generate_interfaces. This fixes it by exporting the python
library target using an existing CMake macro for that purpose called
rosidl_export_typesupport_targets() and amen_export_targets()

I works by adding a variable
"${PROJECT_NAME}_TARGETS__rosidl_generator_py" which is set when the
interface package is `find_package()`d. That variable contains the
targets generated by `rosidl_generator_py` so that downstream interface
packages can depend on it.

Signed-off-by: Shane Loretz <sloretz@osrfoundation.org>
@sloretz sloretz force-pushed the fix_python_assuming_library_names branch from 277ae86 to ffb0eea Compare January 4, 2022 19:45
@sloretz
Copy link
Contributor Author

sloretz commented Jan 4, 2022

CI re-run

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status
    • Re-run to see if test failures are consistent: Build Status
    • All appear in the repeated job except launch_testing_ros.test.examples.set_param_launch_test.set_param_launch_test, investigating.

@sloretz
Copy link
Contributor Author

sloretz commented Jan 10, 2022

launch_testing_ros.test.examples.set_param_launch_test.set_param_launch_test

I'm unable to reproduce this failure in a local windows VM. It's flakiness seems to be a known issue: ros2/launch_ros#280

@sloretz
Copy link
Contributor Author

sloretz commented Jan 10, 2022

CI re-run one last time because of flaky tests above (build: --packages-above-and-dependencies rosidl_generator_py test: --packages-above rosidl_generator_py)

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Windows Build Status

@sloretz
Copy link
Contributor Author

sloretz commented Jan 11, 2022

CI LGTM, only two windows test failures are rosbag2 ones that are also in the nightly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants