Remove unused dependency to save build time

[mini-1235]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses
Primary OS tested on	Ubuntu
Robotic platform tested on	tb4 sim
Does this PR contain AI generated software?	No
Was this PR description generated by AI software?	Out of respect for maintainers, AI for human-to-human communications are banned

---

Description of contribution in a few bullet points

Recently, I noticed that it takes a long time to build nav2 from source on my machine, I also found that there are some unused packages in CMakelist and package.xml, this PR removed those are unused, hopefully this saves a little bit build time

Description of documentation updates required from your changes

Description of how this change was tested

---

Future work that may be required in bullet points

For Maintainers:

• Check that any new parameters added are updated in docs.nav2.org
• Check that any significant change is added to the migration guide
• Check that any new features OR changes to existing behaviors are reflected in the tuning guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists
• Should this be backported to current distributions? If so, tag with backport-*.

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

Do you notice a difference from these changes?

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mini-1235]

Do you notice a difference from these changes?

Yes, on my machine (XPS 15 9020), it saves around 30 seconds

I will do a second check tonight, there are probably more that I can remove

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

This is kind of odd that its failing to build in time. In this file, there are 3x instances of v36. Bump to v37 and see if that helps. It may not, but busting the cache is a first step before digging deeper.

[mergify]

@mini-1235, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[SteveMacenski]

@mini-1235 rebase once #5409 is merged (in the next hour or so) and this should turn over and I can merge it :-) CI for some reason has broken past the 1 hour mark per job and I'm making a semi-temporary workaround to get things going again.

Make sure to also handle the merge conflict.

[mini-1235]

@mini-1235 rebase once #5409 is merged (in the next hour or so) and this should turn over and I can merge it :-) CI for some reason has broken past the 1 hour mark per job and I'm making a semi-temporary workaround to get things going again.

Make sure to also handle the merge conflict.

Ahh ok, just saw this, I will rebased once #5414 is done

[SteveMacenski]

@mini-1235 that PR is blocked from the other change for the nav2_utils presently. This puts us at a few blocked PRs stacked up :(

[mergify]

This pull request is in conflict. Could you fix it @mini-1235?

[roncapat]

@mini-1235 have you considered searching also for rclcpp/rclcpp.hpp includes and substitute them with more specific ones, like rclcpp/node.hpp, rclcpp/duration.hpp and similar?

[mini-1235]

@mini-1235 have you considered searching also for rclcpp/rclcpp.hpp includes and substitute them with more specific ones, like rclcpp/node.hpp, rclcpp/duration.hpp and similar?

Not really, I guess that will be a lot of work, but I will check it in a few days

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
nav2_amcl/src/amcl_node.cpp	66.76% <ø> (ø)
...ior_tree/include/nav2_behavior_tree/json_utils.hpp	97.43% <ø> (ø)
...lugins/action/append_goal_pose_to_goals_action.hpp	100.00% <ø> (ø)
...ins/action/extract_route_nodes_as_goals_action.hpp	100.00% <ø> (ø)
..._tree/plugins/action/get_next_few_goals_action.hpp	100.00% <ø> (ø)
..._tree/plugins/action/get_pose_from_path_action.hpp	100.00% <ø> (ø)
...r_tree/plugins/control/pause_resume_controller.hpp	100.00% <ø> (ø)
...tree/plugins/decorator/goal_updated_controller.hpp	100.00% <ø> (ø)
...tree/plugins/decorator/path_longer_on_approach.hpp	100.00% <ø> (ø)
...lugins/action/append_goal_pose_to_goals_action.cpp	100.00% <ø> (ø)
... and 58 more

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mini-1235]

@mini-1235 have you considered searching also for rclcpp/rclcpp.hpp includes and substitute them with more specific ones, like rclcpp/node.hpp, rclcpp/duration.hpp and similar?

I ran ClangBuildAnalyzer on nav2_costmap_2d and nav2_behavior_tree—these two packages alone take about one third of the total build time on my machine. As expected, rclcpp/rclcpp.hpp is a very expensive header:

**** Expensive headers:
403973 ms: /root/nav2_ws/install/nav2_ros_common/include/nav2_ros_common/nav2_ros_common/node_utils.hpp (included 135 times, avg 2992 ms), included via:
  14x: gtest.h 
  9x: test_behavior_tree_fixture.hpp 
  6x: pose_stamped.hpp 
  5x: string.hpp lifecycle_node.hpp state.hpp 
  2x: battery_state.hpp 
  2x: spin_action.hpp bt_action_node.hpp 
  ...

382040 ms: /opt/ros/rolling/src/gtest_vendor/include/gtest/gtest.h (included 74 times, avg 5162 ms), included via:
  74x: <direct include>

377506 ms: /opt/ros/rolling/include/rclcpp/rclcpp/rclcpp.hpp (included 125 times, avg 3020 ms), included via:
  27x: test_action_server.hpp 
  14x: gtest.h node_utils.hpp 
  6x: <direct include>
  5x: string.hpp lifecycle_node.hpp state.hpp node_utils.hpp 
  4x: pose_stamped.hpp node_utils.hpp 
  4x: test_behavior_tree_fixture.hpp node_utils.hpp 
  ...

144634 ms: /opt/ros/rolling/include/behaviortree_cpp/behavior_tree.h (included 143 times, avg 1011 ms), included via:
  42x: gtest.h 
  32x: bt_factory.h 
  9x: test_behavior_tree_fixture.hpp bt_factory.h 
  6x: pose_stamped.hpp test_behavior_tree_fixture.hpp 
  2x: gtest.h test_behavior_tree_fixture.hpp 
  2x: battery_state.hpp test_behavior_tree_fixture.hpp 
  ...

129436 ms: /root/nav2_ws/src/navigation2/nav2_behavior_tree/include/nav2_behavior_tree/utils/test_action_server.hpp (included 32 times, avg 4044 ms), included via:
  29x: <direct include>
  3x: gtest.h 

114667 ms: /opt/ros/rolling/include/std_msgs/std_msgs/msg/string.hpp (included 17 times, avg 6745 ms), included via:
  12x: <direct include>
  1x: progress_checker_selector_node.hpp 
  1x: smoother_selector_node.hpp 
  1x: goal_checker_selector_node.hpp 
  1x: controller_selector_node.hpp 
  1x: planner_selector_node.hpp 
  ...

But since we are not following the "include what you use" principle in this repo, refactoring such large packages to replace broad includes would require extensive changes. For this PR, I will focus on improving the CMakeLists and only optimize header includes in smaller packages. Sorry about that :(

[mini-1235]

To be honest, I am not really satisfied with this PR, so I guess I will close this temporarily :(

[SteveMacenski]

Ok! Sorry to hear that - I’m ok with another philosophy for includes. Maybe this would be good to file a ticket and provide this different philosophy, rationale, and what we should do differently (maybe a couple of examples?). If it speeds up build times and we can document it in our contribution guide, I’m definitely open to improvements 🙂