Standardize CMake files in all Nav2 packages using ament_cmake_auto

[pranavk-2003]

Feature request

Feature description

I recently came across ament_cmake_auto and was wondering if it would be good if implemented for the packages of nav2 by making a ament_cmake_auto helper macros in place of manually calling find_package(), ament_target_dependencies(), and ament_package().

Implementation considerations

I think it could be implemented in the existing nav2_package macro. Is it viable to implement?Let me know i would like to hear any thoughts.Also would be interested in implementing .suggestions are always welcomed:)

[SteveMacenski]

I tend to prefer not hiding these details and there are times when we want to disable things like tests or certain linter profiles that an auto-script like this would not easily allow for. Would this let us disable certain stages like that and how much does this automate? It might be worth experimenting with a demo package and giving us back your experience :-)

[JWhitleyWork]

I've been using ament_cmake_auto for the last 4 ROS2 releases. Here are some pros and cons of the current implementation (could always be "fixed up" to correct many of these):

Pros

• Significantly reduces maintenance simply by making package.xml the single-source-of-truth for ROS dependencies (using ament_auto_find_build_dependencies() to parse package.xml instead of having to have the list in 2 places)
• In many cases, ament_auto_add_executable and ament_auto_add_library do exactly what you want (others, not so much, but arguments like NO_TARGET_LINK_LIBRARIES can resolve most of these)
• ament_auto_package automatically handles things like installing all ament_auto_-added libraries and executables, installing an include folder in the correct location (if found), and installing folders and files to share/${PROJECT_NAME} through a single argument

Cons

• System dependencies must still be find_package()'d separately because rosdep keys don't tell you the format of the targets or CMake variables generated by a system-installed package
• ament_cmake_auto does not currently use "modern" CMake by exporting targets. It instead currently only exports include directories and libraries (though a PR has been introduced to work around this to some extent)
• target_link_libraries can only be used with "all keyword" or "all plain" signatures (e.g. target_link_libraries(target PUBLIC library) vs target_link_libraries(target library)) when linking against a single target and because ament_auto_add_ macros use target_link_libraries internally in several locations without keywords, doing something like the following is not currently supported:

ament_auto_add_library(my_lib SHARED src/my_lib.cpp)
# Below fails to parse because "plain" signatures are used in the macro above
target_link_libraries(my_lib PRIVATE third_party_lib)

• Package documentation is pretty non-existent except in the CMake macro definitions in the package itself

Hope this helps. Happy to answer any other questions you have about this package.

[ajtudela]

• ament_cmake_auto does not currently use "modern" CMake by exporting targets. It instead currently only exports include directories and libraries (though a PR has been introduced to work around this to some extent)
• target_link_libraries can only be used with "all keyword" or "all plain" signatures (e.g. target_link_libraries(target PUBLIC library) vs target_link_libraries(target library)) when linking against a single target and because ament_auto_add_ macros use target_link_libraries internally in several locations without keywords, doing something like the following is not currently supported:

These two are the main disadvantages. By using the targets and the keyworks PUBLIC / PRIVATE, the downstream packages only need to link against the exact target they require, rather than all dependencies, thereby reducing compilation time.

[pranavk-2003]

I see the concerns you guys have,so maybe instead of standardizing it across all the packages ,it can be only implemented to certain packages, i had nav2_rviz_plugins , nav2_utils in mind.do these dodge the cons? And also is it even worth having this ament_cmake_auto all over? I can try a POC if it is.

[SteveMacenski]

Unfortunately, I wouldn't want to change any if we don't change all (eventually). Nav2 is a large codebase and having consistency across the entire repository in terms of style, tooling, and recipes is important so that contributors can understand and develop on the stack with the lowest friction possible.

Some great lengths were went to by Chris Lalancette to update Nav2 to modern CMake and I do not want to effectively revert that

[pranavk-2003]

Unfortunately, I wouldn't want to change any if we don't change all (eventually). Nav2 is a large codebase and having consistency across the entire repository in terms of style, tooling, and recipes is important so that contributors can understand and develop on the stack with the lowest friction possible.

Some great lengths were went to by Chris Lalancette to update Nav2 to modern CMake and I do not want to effectively revert that

Oh right , makes sense.Anyways thank you for answering my doubts

[SteveMacenski]

OK - I think this can be closed then. Sorry @pranavk-2003 :( I'm happy to have your contributions and help, even if this one wasn't the one

[pranavk-2003]

OK - I think this can be closed then. Sorry @pranavk-2003 :( I'm happy to have your contributions and help, even if this one wasn't the one

Not a Problem! i'll try contributing in some other ways.