Summary
While reviewing ROS 2 package dependency metadata, I noticed that rmf_task appears to use rmf_traffic directly, but rmf_traffic does not seem to be declared in rmf_task/package.xml.
This may make the package rely on rmf_battery or another intermediate package to provide rmf_traffic transitively.
Evidence
Direct usage
rmf_task directly includes rmf_traffic headers in production headers:
include/rmf_task/Phase.hpp:24: #include <rmf_traffic/Time.hpp>include/rmf_task/Log.hpp:27: #include <rmf_traffic/Time.hpp>include/rmf_task/Header.hpp:21: #include <rmf_traffic/Time.hpp>include/rmf_task/Header.hpp:22: #include <rmf_traffic/agv/Graph.hpp>include/rmf_task/Estimate.hpp:26: #include <rmf_traffic/Time.hpp>include/rmf_task/Estimate.hpp:27: #include <rmf_traffic/agv/Planner.hpp>include/rmf_task/State.hpp:26: #include <rmf_traffic/agv/Planner.hpp>
The manual source review found extensive use of rmf_traffic::Time, rmf_traffic::Duration, rmf_traffic::Trajectory, rmf_traffic::agv::Planner, and rmf_traffic::agv::Plan::Start.
Current package.xml
I could not find a direct declaration of rmf_traffic in rmf_task/package.xml. The package currently declares:
<depend>rmf_battery</depend>
<depend>rmf_utils</depend>
Observed during build/test
During build/test tracing, files from rmf_traffic were accessed, for example:
lib/rmf_traffic/cmake/rmf_traffic-config.cmakelib/rmf_traffic/cmake/rmf_traffic-targets.cmakeshare/colcon-core/packages/rmf_trafficlib/librmf_traffic.so
Transitive path
The dependency appears to be reachable transitively through:
rmf_task -> rmf_battery -> rmf_traffic
Suggested fix
If these traffic planning types are direct dependencies of rmf_task, would it make sense to add:
<depend>rmf_traffic</depend>
Notes
This issue is not claiming that the package currently fails to build. The concern is that the package directly uses rmf_traffic while relying on a transitive dependency path to make it available. The observation is based on package metadata, source usage, dependency closure analysis, and build/test file-access tracing.
Could you please confirm whether this dependency is intentionally left implicit through the transitive dependency path shown above, or whether adding an explicit dependency to package.xml would be appropriate?
I would be happy to open a small PR adding the dependency if that matches the intended package metadata.
Summary
While reviewing ROS 2 package dependency metadata, I noticed that
rmf_taskappears to usermf_trafficdirectly, butrmf_trafficdoes not seem to be declared inrmf_task/package.xml.This may make the package rely on
rmf_batteryor another intermediate package to providermf_traffictransitively.Evidence
Direct usage
rmf_taskdirectly includesrmf_trafficheaders in production headers:include/rmf_task/Phase.hpp:24:#include <rmf_traffic/Time.hpp>include/rmf_task/Log.hpp:27:#include <rmf_traffic/Time.hpp>include/rmf_task/Header.hpp:21:#include <rmf_traffic/Time.hpp>include/rmf_task/Header.hpp:22:#include <rmf_traffic/agv/Graph.hpp>include/rmf_task/Estimate.hpp:26:#include <rmf_traffic/Time.hpp>include/rmf_task/Estimate.hpp:27:#include <rmf_traffic/agv/Planner.hpp>include/rmf_task/State.hpp:26:#include <rmf_traffic/agv/Planner.hpp>The manual source review found extensive use of
rmf_traffic::Time,rmf_traffic::Duration,rmf_traffic::Trajectory,rmf_traffic::agv::Planner, andrmf_traffic::agv::Plan::Start.Current package.xml
I could not find a direct declaration of
rmf_trafficinrmf_task/package.xml. The package currently declares:Observed during build/test
During build/test tracing, files from
rmf_trafficwere accessed, for example:lib/rmf_traffic/cmake/rmf_traffic-config.cmakelib/rmf_traffic/cmake/rmf_traffic-targets.cmakeshare/colcon-core/packages/rmf_trafficlib/librmf_traffic.soTransitive path
The dependency appears to be reachable transitively through:
Suggested fix
If these traffic planning types are direct dependencies of
rmf_task, would it make sense to add:Notes
This issue is not claiming that the package currently fails to build. The concern is that the package directly uses
rmf_trafficwhile relying on a transitive dependency path to make it available. The observation is based on package metadata, source usage, dependency closure analysis, and build/test file-access tracing.Could you please confirm whether this dependency is intentionally left implicit through the transitive dependency path shown above, or whether adding an explicit dependency to
package.xmlwould be appropriate?I would be happy to open a small PR adding the dependency if that matches the intended package metadata.