Robotics Systems Types

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?

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.

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?