When is ${catkin_EXPORTED_TARGETS} needed
This is basically a follow-up to #q285772 During my use of ROS, I adopted to call the following line on any (C++) target that I try to build:
add_dependencies(MYTARGET ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})
using ${${PROJECT_NAME}_EXPORTED_TARGETS}
only when building msg/srv/actions/dynamic_reconfigure in the package I am workin on, and ${catkin_EXPORTED_TARGETS}
always.
This is a constant source of error, as well in the above cited question. Thus, I always adviced People to follow the same strategy.
In a comment to the above question, @gvdhoorn described the approach to always use ${catkin_EXPORTED_TARGETS}
as "cargo-cultish" (nice term :-D)
re: adding catkin_EXPORTED_TARGETS: that's a bit cargo cult-ish. I wouldn't add that unless it's needed.
Checking the documentation (e.g. wiki, catkin docs 1 or catkin docs 2) I'm not quite sure when to use it.
The wiki suggest that:
If you have a target which (even transitively) depends on some other target that needs messages/services/actions to be built, you need to add an explicit dependency on target catkin_EXPORTED_TARGETS, so that they are built in the correct order. This case applies almost always, unless your package really doesn't use any part of ROS. Unfortunately, this dependency cannot be automatically propagated. (some_target is the name of the target set by add_executable()):
add_dependencies(some_target ${catkin_EXPORTED_TARGETS})
This is basically saying: You Need it always (solution 1).
The catkin docs rather say, if you Need any msg/srv/action/dynamic_reconfigure from another catkin package (solution 2).
Which is the right way to go? I'd be happy for any insights.
I think solution 1 becomes more important with the number of packages you build from source for the first time. Imagine the theoretical case where you'd like to build whole ROS up to your package from source. If your package's targets are missing the dependency on
${catkin_EXPORTED_TARGETS}
, they could be built earlier than the messages from the dependencies are generated. Or at least this is how I understand it. Thanks to the ordering catkin creates, builds with-j1
should succeed, while multi-job builds could run into this issue.