[Question] Usage of CPP Preprocessor macros for different ROS distros

[MichaelT64]

While trying to adapt the new features in the main branch to the Humble branch I tried to use CPP Preprocessor capabilities.
I found just a few differences between humble and main for compiling, which can be solved in the following way, e.g.:

#ifdef humble
nav2_util::copy_all_parameters(node, client_node_);
#else
rclcpp::copy_all_parameter_values(node, client_node_);
#endif

In the corresponding CMakeLists.txt FiIes I added the line:
add_compile_definitions( humble )
Due to the lack of cmake knowledge I was not able to use the ROS_DISTRO environment variable or was able to add the compile definition just in one CMakeLists.txt file.

I wonder if this could be a possibility to simplify the development of new features for different ROS distros.

Unfortunately I am just starting with Nav2 so I cannot asses weather the functionality is the exact same but the general way should be possible.

[SteveMacenski]

I don't doubt that you could probably do this by setting a cmake flag on building to render as a preprocessor https://stackoverflow.com/questions/9639449/cmake-how-to-pass-preprocessor-macros

This feels like a more general C++/CMake question than anything related to Nav2 though. We're not looking to have main which targets Rolling to also support Humble. We make big architectural changes and while today it is probably possible, it may not always be possible due to massive breaking changes that there is no eq. for in older distributions.

If someone (i.e. you) wanted to have a main branch that targets humble support, we could add it to our branch set in the project, but someone (i.e. you) would have to be committed to maintaining it.

[SteveMacenski]

Thoughts?

[MichaelT64]

Hi @SteveMacenski, thanks for your offer and sorry for the late answer.
I am just a hobbyist with limited resources in time and testing possibilities.
In the meantime I made some progress in an own fork https://github.com/MichaelT64/navigation2 with a brief description of the changes and the motivation of my work in the ChangesForHumble file.
What are the code formatting rules for Nav2? I can't find anything about this (working with Visual Studio Code), so many changes occurred because of (automatic) reformatting the code.

[SteveMacenski]

Understood, I think that this is not a change that I would be willing to make without a stake holder committing to its upkeep due to my comment above:

We make big architectural changes and while today it is probably possible, it may not always be possible due to massive breaking changes that there is no eq. for in older distributions.

#4148 is a good example of one of these updates that would be a real pain to try to setup if preprocessors to backport with humble. That one is probably possible, but touches alot of files and would require active upkeep. So I suppose I would say that if you can't commit to keeping a rolling-current-LTS branch going, its probably best that it stays on your fork and possibly make a remark to the community on the Nav2 Slack or Discourse that it exists for those that want it (tagged to some version)

---

What are the code formatting rules for Nav2?

We use the ROS 2 default styling, which is a google-ish styling. If you run ament_cpplint ament_uncrustify etc they have the profiles built in. colcon test executes these as part of its testing suite so when you test your code, errors in formatting will also come up.

[SteveMacenski]

https://github.com/open-navigation/navigation2/tree/iron_main

This branch builds main on Iron