Allow explicit selection of built converters
|Target version:||Robotics Service Bus - rsb-0.18|
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...
#2 Updated by J. Moringen over 7 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 7 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?
#5 Updated by S. Wrede over 7 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?