Replace rosbag2_cpp typesupport helpers with rclcpp typesupport helpers

[authaldo]

Hey @facontidavide ,

first of all thanks for making such an amazing tool availabe as open source!

While trying to update a docker image for Jazzy, I stumbled upon an issue that the plotjuggler ros plugins currently do not build against the current jazzy branch.
More specifically, this backported commit removed the typesupport helpers header from rosbag2_cpp. Consequently, I replaced them the same way they did it in the rosbag repository (with their rclcpp equivalent).

I solely tested this against Jazzy as that is the only version I am currently using , but given it is a backported commit I assume rolling to face the same problem. Not sure about older versions.

[facontidavide]

does it work in Humble?

[facontidavide]

as expected (see CI), this change is not backcompatible with Humble.

If you fix it, I will be happy to merge it

[authaldo]

What would be your preferred way to fix this?

I like the fact that this repository has a single main branch compatible with all active ROS versions. However, since the change doesn't seem to be backported to Humble, these versions have already diverged with respect to the changed header (humble contains the header, while e.g. for jazzy the file has been removed.
Honestly, I would have expected to see this in failing jazzy and rolling pipelines on the current main, however, it may be that the change hasn't found its way into the latest images yet? Or am I missing something else? 🤔

In my view there are a few options:
a) try to achieve a humble backport of the typesupport_helper commit so that all three active versions share this change (not sure whether this is possible)
b) create a separate humble branch without this MR
c) detect the ROS version in the plugin code and handle the difference there

[facontidavide]

Humble is detected by cmake and a defintion is added to compile code conditionally.

https://github.com/PlotJuggler/plotjuggler-ros-plugins/blob/main/src/CMakeLists.txt#L50-L54

Therefore, a clear approach would be hide those functions behing our own, and internally use #ifdef to use one implementation or the other.

Anyway, as long as CI is happy and there are no conflict, I will be happy to merge

[facontidavide]

pre-commit :)

[authaldo]

CI should be fine now, please let me know if anything else is missing :)

[wentasah]

Is there something preventing the merge of this PR? It would fix the build failure in rolling, which will soon be released as lyrical (I think).

[authaldo]

Thanks @wentasah for bringing this up again, I had almost forgotten about this PR.

I just discovered that the CI for the main branch is failing (just after the merge) and am not yet fully sure how that relates to my changes. It seems like the CI hasn't been triggered again before the merge, only afterwards.
Thus, the green CI has potentially been over two months old.

Nonetheless, the log output of the jobs is a bit weird:
For the rolling job, the failure to find ament_package indicates in my view a more general problem with the CI, as that part hasn't been touched in the changes.

The humble failure however directly relates to the changes, as it seems like the wrong branch is chosen within the wrapper file. Not sure why that happens, since the log output from within cmake correctly identifies the humble env, and the mechanism with the define had already worked in the PR CI.
Additionally, I am not able to reproduce the failure against the osrf/ros:humble-desktop image 🤔