New class loader

[skasperski]

Changes the plugin-manager so that it uses the current version of class_loader. In a ROS setup it means that the class loader from ROS' apt-packages can be used.

[chhtz]

In a Rock-workspace class_loader is not found via CMake, it appears.
The first error is (a few similar follow):

CMake Error at /home/dfki.uni-bremen.de/chertzberg/workspace/terrain_exploration/install/share/rock/cmake/Rock.cmake:498 (get_property):
  get_property could not find TARGET class_loader::class_loader.  Perhaps it
  has not yet been created.
Call Stack (most recent call first):
  /home/dfki.uni-bremen.de/chertzberg/workspace/terrain_exploration/install/share/rock/cmake/Rock.cmake:938 (rock_target_definition)
  /home/dfki.uni-bremen.de/chertzberg/workspace/terrain_exploration/install/share/rock/cmake/Rock.cmake:1036 (rock_library_common)
  src/CMakeLists.txt:6 (rock_library)

According to the CMakeCache class_loader_DIR points to /usr/share/class_loader/cmake (which I assume is wrong for a rock workspace).
Do we first need to patch Rock's version of the class_loader to be found correctly by CMake?

[chhtz]

We could try upgrading rock's version of tools/class_loader. It is currently set to indigo-devel tag 0.3.8 in rock.core with a patch added.
Just removing the patch and going to rolling currently fails because rcpputils is not found (after enabling CLASS_LOADER_IGNORE_AMENT and removing console_bridge_vendor from the CMakeLists)
I did not continue trying.

[skasperski]

I am confused about console_bridge. What is it? Is the console_bridge from https://github.com/rock-core/base-console_bridge the same that is installed via libconsole-bridge-dev? I would guess not, but how are they related?

[planthaber]

https://github.com/rock-core/base-console_bridge fakes the ros console bridge api to be able to use those packages witout dependency to roscpp/rclcpp

[skasperski]

It looks like the plugin_manager is mostly used by envire, where it is actually optional. Do we know, if this envire::ClassLoader (which seems to be a rather thin wrapper around plugin_manager) is actually used in our stack? Maybe in mars (@malter )? Maybe we can just safely remove it, else I would suggest to look for another Plugin implementation or see if we can implement this here to work without the class_loader, which is in its current form a part of the ROS eco system.

[planthaber]

We could compile classlaoder with a differnet libname so the plugin_manager can specifically link to that version, like "libclass_loader_envire.so"? Wehn we also adapt the cmake config and pkg-config, we shouldn't ha an issue with having both installed

[skasperski]

I looked a bit deeper into it, and it keeps getting more confusing to me. Apparently console_bridge (https://github.com/ros/console_bridge) is ros independent and is meant as a interface to some framework specific logging mechanism. So in order to use it, one would have to use the CONSOLE_BRIDGE_LOG_DEBUG / INFO etc... macros inside the code, or am I missing something here? This interface should then be implemented for rock, as was done for the ros world.

What does base/console_bridge achieve in its current state?

[chhtz]

What does base/console_bridge achieve in its current state?

I think base/console_bridge does exactly what you describe, i.e. it provides the CONSOLE_BRIDGE_LOG_<LEVEL> macros and calls (RoCK) base-logging functions with it.

[chhtz]

We could compile classlaoder with a differnet libname so the plugin_manager can specifically link to that version, like "libclass_loader_envire.so"? Wehn we also adapt the cmake config and pkg-config, we shouldn't ha an issue with having both installed

If I understand @skasperski correctly the main issue is to get (a current version of) https://github.com/ros/class_loader/ compile (and install) properly without pulling in lots of ROS dependencies.

[chhtz]

Shall we file an issue at https://github.com/ros/class_loader/tree/rolling whether it is possible to remove the dependency to rcpputils and rcutils?
class_loader claims to be ROS-independent, while the latter libraries are core ROS libraries. The remaining dependencies are really easy to resolve, I assume.

[chhtz]

Shall we file an issue at https://github.com/ros/class_loader/tree/rolling whether it is possible to remove the dependency to rcpputils and rcutils?

--> ros/class_loader#211