Feature #1476

Allow explicit selection of built converters

Added by S. Wrede over 6 years ago. Updated about 2 years ago.

Status:FeedbackStart date:04/25/2013
Priority:NormalDue date:
Assignee:-% Done:

30%

Category:Build System
Target version:Robotics Service Bus - rsb-0.18

Description

In my current scenario, I want to explicitly switch off compilation for OpenCV converters (as OpenCV can not be easily build as a univeral binary on MacOS). Currently, this seems not possible as what is build is completely determined through the found packages in the configuration step.

Once we modularize the converters into separate libraries this shouldn't be a problem any longer. For instance, in this case, the best solution would be to have a dedicated plugin library for OpenCV with a library architecture that matches the installed version of the dependency. Another aspect in favor of the plugin system...

History

#1 Updated by S. Wrede over 6 years ago

  • Subject changed from Allow explicit selection of build converters to Allow explicit selection of built converters
  • Description updated (diff)

#2 Updated by J. Moringen over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 30

We now have separate plugins for the different converter "groups" such as OpenCV (see #1520). However, these plugins only affect registration of converters, the respective functionality of all buildable (that is with satisfied CMake-dependencies) converters is still contained in one shared object, librstconverters.so (or similar), which is not a plugin.

Please explain which further changes are required to resolve this.

#3 Updated by S. Wrede over 6 years ago

Some background information: the situation here (on MacOS) is as follows. Most libraries are build as fat binaries with 32 and 64 bit support, e.g., RSC, RSB and RST. This is fine as these libraries are under our control and we can fix any 32/64bit incompatibilities. The difference that comes with the rst converters is that link against (probably many, in the current approach) specific 3rd party libraries (opencv, naoqi, ...) that come with their own specific dependencies. For instance, in my case, there is no simple way to build OpenCV as a 32/64bit binary and thus I cannot build rst-converters and everything that is dependent on it in this way. The 32/64bit case serves just as one example, I could envision also other cases where, e.g., the 3rd party libraries have conflicting dependencies or other issues.

Splitting up the single librstconverters into separate specific libraries could be a solution to this. Any other ideas?

#4 Updated by J. Moringen over 6 years ago

Wouldn't it be sufficient to provide CMake support for disabling features?

I don't see the benefit of having individual libraries unless we go all the way and also split everything up on the packaging level.

#5 Updated by S. Wrede over 6 years ago

Unfortunately, in a setup where I compile and install as much functionality as possible in a single prefix the compile-time solution doesn't help. Isn't it actually one of the benefits of having plugins that we decouple compile-time from run-time aspects? So, in terms of the OpenCV example: If I am running an rsb-cv process the plugin is loaded and everything is executed as 32bits while the same rsb libraries can run, e.g., an AMARSi application in 64bit processes?

#6 Updated by J. Moringen over 6 years ago

  • Target version changed from rsb-0.9 to rsb-0.10

Further modularising the librstconverters.so library makes sense. However, we should also provide finer grained CMake config files and Debian packages when we do this.

#7 Updated by J. Moringen almost 6 years ago

  • Target version changed from rsb-0.10 to rsb-0.11

#8 Updated by J. Moringen over 5 years ago

  • Category set to Build System

#9 Updated by J. Moringen almost 5 years ago

  • Target version changed from rsb-0.11 to rsb-0.12

#10 Updated by J. Wienke over 4 years ago

  • Target version changed from rsb-0.12 to rsb-0.13

#11 Updated by J. Moringen almost 4 years ago

  • Target version changed from rsb-0.13 to rsb-0.14

#12 Updated by J. Moringen over 3 years ago

  • Target version changed from rsb-0.14 to rsb-0.15

#13 Updated by J. Moringen about 3 years ago

  • Target version changed from rsb-0.15 to rsb-0.16

#14 Updated by J. Moringen over 2 years ago

  • Target version changed from rsb-0.16 to rsb-0.17

#15 Updated by J. Moringen about 2 years ago

  • Target version changed from rsb-0.17 to rsb-0.18

Also available in: Atom PDF