Deprecate C Headers

[CursedRock17]

This pull request is an attempt to help #259, specifically the first task

Rename all .h -> .hpp files. This will have to also have a deprecation warning, and should be done post-Foxy.

Since it's now post-Foxy I did something similar to this message_filters pull request, which was to simply deprecate a .h file with a warning, include the .hpp file, and just copy paste the logic from the .h file into the .hpp file. There were some slight formatting changes that had to be made to make cpplint and uncrustify happy. There is currently a copyrighting problem within the LinearMath files since they seem to be from the bullet library. I would like to know where we should move from this point when it comes to those files.

[ahcorde]

copyright is failing

https://build.ros2.org/job/Rpr__geometry2__ubuntu_noble_amd64/123/testReport/junit/(root)/projectroot/copyright/

[ahcorde]

you should keep here both the h and the hpp

[clalancette]

you should keep here both the h and the hpp

Agreed.

[clalancette]

Besides some of @ahcorde 's inline comments, we will also need to have PRs to the rest of the ROS 2 core to use the .hpp files instead of the .h ones. Also, this is a large enough change that once we are ready to merge it, we should probably send a message to https://discourse.ros.org letting people know that we've done this.

[CursedRock17]

Yeah I figured we would have to extend PRs to various libraries, I have one linked from rviz, but I haven't found anymore, I'll have to do some digging around to find out if I've missed any more of the core ones. As far as the copyrighting goes, I believe those inline comments were the missing piece, I've submitted a fix.

[CursedRock17]

Updated downstream packages:

• Fix Deprecated tf2 headers rviz#1289
• Deprecating tf2 C Headers ros2_documentation#4828
• Deprecating tf2 C Headers cartographer_ros#75
• Deprecating tf2 C Headers ros/geometry#244
• Deprecating tf2 C Headers ros/geometry2#573
• Deprecate tf2 C Headers ros/geometry_tutorials#87
• Deprecate c headers ros-perception/imu_pipeline#25
• Deprecating tf2 C Headers ros-perception/laser_geometry#98
• Deprecate c headers ros-perception/laser_filters#206
• Deprecating tf2 C Headers ros-perception/image_pipeline#1039
• Deprecating tf2 C Headers ros-perception/perception_pcl#469
• Deprecating tf2 C Headers ros-controls/ros2_controllers#1325
• Deprecating tf2 C Headers ros-navigation/navigation2#4732
• Deprecate tf2 C Headers ros-industrial/industrial_training#420

These were all the repositories that I could find, within the core ROS organizations, in which tf2 was utilized. There are likely thousands of repositories which are going to have warnings, which are warnings as to not break API, but I certainly wouldn't mind making a general PSA.

[Timple]

Would it make sense to provide .hpp files for all active distros? With as only content the include of the .h file.

This would mean all projects that do not have a branch per release can use this syntax already. Preventing ugly statements like this everywhere: https://github.com/autowarefoundation/autoware.universe/blob/9bd0f77c255edcff129ff08d190a5fdd8c45b6dc/localization/yabloc/yabloc_common/src/pub_sub.cpp#L18

For rolling we can keep the deprecation flag, not for older distros.

[CursedRock17]

Yeah I don't see much of a compile downside, just a weirder file structure for older distributions. I assume we would just never phase out the .h files unlike the rolling branch in which we can remove them in L-Turtle. I would be able to add this "backport" later today if that's something we agree on.

Also there already seems to be some consensus in the other core repositories:

• Deprecating tf2 C Headers ros-perception/perception_pcl#469

we should create backwards compatibilty headers that emit compile warnings so users have time to migrate to the new headers.

• Deprecating tf2 C Headers ros-controls/ros2_controllers#1325

Can you add conditioning in the code so that from rolling on it uses the .hpp, and in the prior versions it uses the .h version?

[CursedRock17]

When I get back to my workstation later today, I can roll these improvements (whitespacing & visibility_control) onto the other branches I adjusted for the backport.

[clalancette]

Pulls: #720, ros2/rviz#1289, ros-perception/laser_geometry#98
Gist: https://gist.githubusercontent.com/clalancette/b83127091186f2489c09c4c787585861/raw/3c16fd56b4d645d09b9cadf800da79cbfd1acbaf/ros2.repos
BUILD args:
TEST args:
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/14792

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[clalancette]

So there are at least two problems here:

1. We need a PR to interactive_markers to deal with the change.
2. Windows doesn't seem to like the #warning construct, so we may have to do something special for Windows there. Maybe something like https://github.com/ros2/common_interfaces/blob/473511f5807610bb8ed7744dfd2986dba4601fa6/sensor_msgs/include/sensor_msgs/point_cloud_conversion.hpp#L41-L49

[CursedRock17]

Hopefully windows likes the current implemention. Also backport PRs are ready to go as well.

[ahcorde]

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[ahcorde]

There are still some warnings

[CursedRock17]

I think it's just the repos being built, I changed up interactive_markers which seems to be the repository throwing out some warnings as it's still on the rolling branch. My updated branch stops using the .h files that are the only ones triggering the warnings, which should be ok.

[MichaelOrlov]

@ahcorde Could you please try to rerun CI?

[ahcorde]

included PRs: geometry2, laser_geometry, RViz2 and interactive_markers

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[ahcorde]

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[Ryanf55]

Iron I guess?

Can you do humble if it's not too much work?

What's the story on humble? Our work environment is now broken from the docker images supplied from ros:humble-ros-core.

Currently, in this broken state, we have the following installed.

• ros-humble-tf2 version 0.25.9-1jammy.20241128.023902
• ros-humble-tf2-eigen version 0.25.11-1jammy.20250114.170617

In tf2_eigen.hpp, it includes "tf2/convert.hpp".

Then, the files that exist:

$ ls /opt/ros/humble/include/tf2/tf2/ -1
LinearMath
buffer_core.h
buffer_core_interface.h
convert.h
exceptions.h
impl
time.h
time_cache.h
transform_datatypes.h
transform_storage.h
utils.h
visibility_control.h

Where's the deprecation period and how did this get all the way through the build farm into a docker image with debians that don't work together. Why isn't tf2-eigen expressing a minimum version on tf2 so it fails at configure time?

Sorry to be blunt, but this is just frustrating.

[clalancette]

• ros-humble-tf2 version 0.25.9-1jammy.20241128.023902

• ros-humble-tf2-eigen version 0.25.11-1jammy.20250114.170617

These aren't the same versions, which is why you are having trouble here. The debians that are released should all match as 0.25.11; the fact that they aren't probably means your local scripts are missing an apt-get update somewhere (i.e. it is using a cached layer with tf2, and a new layer with tf2_eigen).

[Ryanf55]

Thanks. If there's any changes we could do to ensure that we fail at configure time rather than build time, I'd be happy to contribute those.