Description
It seems a bit sad to me that important and breaking changes like #572 go through without any evaluation of user-friendliness (in terms of regulations, this would be similar to a RIA - Regulation Impact Assessment) (or was there some kind of evaluation? The PR doesn't mention it and I haven't read about it in PMC meeting logs).
In general, I welcome this step as it brings ROS packages a bit closer to using standardized approaches.
However, how should a developer know whether his/her package should depend on pkg::pkg or ${pkg_TARGETS}? I know the distinction is somewhere along the line of message packages, but how is the developer expected to figure out which ones are they? I guess one solution would be to depend everywhere on ${pkg_TARGETS}, but I thought the motion is towards the modern targets and away from variables…
Currently, the pkg::pkg target is not available for all ament_cmake packages (e.g. rclcpp_components). So instead of just specifying the package to depend on (as was the case with ament_target_dependencies), the developer is now expected to somehow figure out the list of provided targets and select which ones to depend on (unless ${pkg_TARGETS} is used). And even in the majority of packages that do contain a pkg::pkg target, it seems that the rosidl targets are not a part of this target. That's probably why #572 suggests to depend on ${pkg_TARGETS} for message packages.
This leads to a pretty complicated process when you're developing a new package that depends on other ROS packages. (Old packages could benefit from the warning added in #572, but still).
@traversaro agreed with me on Discourse that it wouldn't be a bad idea to have a single and predictable name for a target that contains everything needed to link a ROS package against that package. It could be pkg::pkg or something even easier, like pkg::build_export_deps (a better name could probably be found). I don't see deep enough into ament_cmake to figure out whether adding the rosidl targets to pkg::pkg is feasible or not.