search

jhu-lcsr-forks / rtt_ros_integration

Orocos-ROS integration libraries and tools
1 stars 2 forks source link

rtt_ros: Why is a new <plugin_depend> tag needed to declare RTT dependencies? #3

Open meyerj opened 11 years ago

meyerj commented 11 years ago

This is only a feedback comment as requested by @jbohren, not a bug report.

The rtt_ros README states that a new <rtt_ros><plugin_depend>PKG_NAME</plugin_depend></rtt_ros> tag has been introduced to import dependent packages via ros.import(). I do not really understand why this is needed, beside the weak reasons mentioned in the README.

The catkin dependency tags are indeed quite confusing, but <run_depend> is exactly what would be needed here:

Run Dependencies specify which packages are needed to run code in this package, or build libraries against this package. This is the case when you depend on shared libraries or transitively include their headers in public headers in this package (especially when these packages are declared as (CATKIN_)DEPENDS in catkin_package() in CMake).

<run_depend> is what translates to package dependencies when creating binary packages, e.g. on the ROS buildfarm. Adding another <plugin_depend> tag does IMHO not help to reduce confusion. Specifying packages in <plugin_depend> does not release users to additionally adding them as runtime dependencies if they want to obey the specification, especially for released packages.

Furthermore, the tag name plugin_depend is misleading as not only RTT plugins, but also RTT typekits (afaik a special type of plugin) and component libraries could be imported from other packages.

jbohren commented 11 years ago

I'm definitely open to feedback on this!

The short answer is:

  1. To support the current behavior of the RTT ComponentLoader by importing deps described in package manifests
  2. To be explicit about which plugins get loaded when you import a given package. If you just imported all <run_depend> tags, then you couldn't distinguish between a package needed at runtime for other purposes, but whose plugins you didn't want to automatically import
  3. Searching all run_depend tags is time consuming
  4. Many run_depend tags are system dependencies (formerly rosdeps), and not actually catkin packages
  5. To enable a package to list a number of packages from which plugins should be loaded, even if that package doesn't build any plugins

The current ComponentLoader::import() functions don't do any sort of runtime dependency-chain-loading. Instead they opt to link the shared libraries together at compile time as explained in http://www.orocos.org/book/export/html/3615:

# Link with the OCL Deployment component:
orocos_use_package( ocl-deployment )

This macro has a similar effect as putting this dependency in your manifest.xml file, it sets the include paths and links your libraries if OROCOS_NO_AUTO_LINKING is not defined in CMake (the default). Some packages (like OCL) define multiple .pc files, in which case you can put the ocl dependency in the manifest.xml file and use orocos_use_package() to use a specific ocl .pc file.

The nice thing about not doing this, is that it means fewer things need to be recompiled if plugins change upstream in the dependency graph.

Furthermore, the tag name plugin_depend is misleading as not only RTT plugins, but also RTT typekits (afaik a special type of plugin) and component libraries could be imported from other packages.

Yeah, this could use a better name, maybe just "auto_import" or something like that, if we stick with this method.