Feature request

Feature description

Many packages contain helpful macro variables to designate the version of the library such as with Eigen, Boost, ITK, etc. This becomes increasingly important with libraries that change or add to their interface fairly regularly. I propose that rclcpp define such variables. For example,

#define RCLCPP_VERSION "11.2.0"
#define RCLCPP_VERSION_MAJOR 11
#define RCLCPP_VERSION_MINOR 2
#define RCLCPP_VERSION_PATCH 0

This will allow for package writers and package maintainers to write code that works for multiple versions of rclcpp by using preprocessor directives, like #if RCLCPP_VERSION > 11. Otherwise, it becomes burdensome to handle such situations.

One example of a project rolling their own solution to a lack of such macro variables is https://github.com/1r0b1n0/libros2qt where they get around a deprication of rclcpp::executor::Executor in favor of rclcpp::Executor.

Furthermore, on a larger note, ROS2 in general does not have such macro variables, but ROS 1 does with its roscpp package (see https://answers.ros.org/question/9562/how-do-i-test-the-ros-version-in-c-code/). Such a feature would help fill the gap, especially if the same macro variables can be defined in ROS2, i.e., ROS_VERSION_MAJOR, ROS_VERSION_MINOR, ROS_VERSION_PATCH, and ROS_VERSION.

Implementation considerations

Such defines are usually autogenerated by CMake when the version is specified in the project() declaration and the project uses a configure_file() call on a config.hpp.in file. For example

CMakeLists.txt

project(rclcpp VERSION 11.2.0)

configure_file("include/rclcpp/rclcpp_config.hpp.in" "${CMAKE_CURRENT_BINARY_DIR}/include/rclcpp/rclcpp_config.hpp")

rclcpp_config.hpp.in

#ifndef RCLCPP__RCLCPP_CONFIG_HPP_
#define RCLCPP__RCLCPP_CONFIG_HPP_

#define RCLCPP_VERSION  "${PROJECT_VERSION_MAJOR}"
#define RCLCPP_VERSION_MAJOR ${PROJECT_VERSION_MAJOR}
#define RCLCPP_VERSION_MINOR ${PROJECT_VERSION_MINOR}
#define RCLCPP_VERSION_PATCH ${PROJECT_VERSION_PATCH}

#endif // RCLCPP__RCLCPP_CONFIG_HPP_

One obvious problem with this approach is the duplication of the version number in both package.xml and CMakeLists.txt. It may be that ament can be enhanced to autogenerate such a configuration header file with version information using the version from package.xml. But these are larger forward-thinking design decisions that do not need to be resolved before this project can start adopting this common library writing practice.

Either way, I see this as a necessary feature for those who intend to maintain packages using rclcpp for a long period of time and over multiple releases of ROS2.