Revision history [back]

This likely "works" because geometry_msgs will be installed with a regular ROS 1 installation.

So even if you don't add geometry_msgs as a (build) dependency to your CMakeLists.txt and package.xml, /opt/ros/$ROS_DISTRO/include will end up on the include path of your compiler/preprocessor (as part of the include paths exported by some other package you (transitively depend on), and it will be able to resolve geometry_msgs/Twist.h to /opt/ros/$ROS_DISTRO/include/geometry_msgs/Twist.h.

Now you could ask: "if this works, then why bother adding (build) dependencies to packages at all?"

The answer would be: because you cannot rely on packages like geometry_msgs to always already have been installed.

A ROS 1 installation without geometry_msgs would be perfectly possible, and in that case, when someone tries to build your package, it would fail, as you've not made the dependency on geometry_msgs explicit, and it will not be detected to be missing before the build is started.

This likely "works" because geometry_msgs will be installed with a regular ROS 1 installation.

So even if you don't add geometry_msgs as a (build) dependency to your CMakeLists.txt and package.xml, /opt/ros/$ROS_DISTRO/include will end up on the include path of your compiler/preprocessor (as part of the include paths exported by some other package you (transitively (transitively) depend on), and it will be able to resolve geometry_msgs/Twist.h to /opt/ros/$ROS_DISTRO/include/geometry_msgs/Twist.h.

Now you could ask: "if this works, then why bother adding (build) dependencies to packages at all?"

The answer would be: because you cannot rely on packages like geometry_msgs to always already have been installed.

A ROS 1 installation without geometry_msgs would be perfectly possible, and in that case, when someone tries to build your package, it would fail, as you've not made the dependency on geometry_msgs explicit, and it will not be detected to be missing before the build is started.