Yarp: Document the meaning of the `EXTRA_CONFIG WRAPPER` parameter in the yarp_prepare_plugin macro and of wrapper key in plugin .ini manifest

[traversaro]

Is your feature request related to a problem? Please describe.

Whenever we have a plugin that can be exposed on the network via a network server (wrapper) device we specify the name of the suitable network server device in two places:

• With the EXTRA_CONFIG WRAPPER=wrappername argument to the yarp_prepare_plugin CMake macro (example: https://github.com/robotology/yarp/blob/eeeb98345d528ef56187b06c3712fdd66fadeb08/src/devices/imuBosch_BNO055/CMakeLists.txt#L9)
• With the wrapper key in the devicename.ini plugin manifest (example: https://github.com/robotology/yarp/blob/eeeb98345d528ef56187b06c3712fdd66fadeb08/src/devices/imuBosch_BNO055/imuBosch_BNO055.ini#L5)

However, I personally do not have a clear idea about the meaning of this two parameters, and their actual behavior. In https://github.com/robotology/yarp/issues/1705 we experience an issue due to my lack of understanding of the role of this parameters. It would be great to have a documentation for this.

Describe the solution you'd like
A section in the documentation of YARP describing the meaning of this parameters.

[jgvictores]

Hi! I'm pretty sure you have a good number of people around there to help you, but documenting here from my understanding just while official documentation isn't out (and adding ideas that might be missed):

• EXTRA_CONFIG WRAPPER=wrappername argument to the yarp_prepare_plugin CMake macro: Affects static libraries, which was more common in the (static) past: YARP plugins were built into yarpdev statically, and you could configure YARP to compile your own plugins into yarpdev too (or compile your own equivalent to yarpdev with your own plugins).
• wrapper key in the devicename.ini plugin manifest: More common in the (shared/dynamic) present, affects yarpdev when loading plugins that are shared/dynamic libraries.

Additional notes:

1. Yes, as commented at #1705, the way to tell YARP that a device is a wrapper (which in general offers server-like interface(s) to a device, and locally opens the wrapped device specified via the subdevice parameter) is by setting wrapper equal to the device name.
2. Extra points: The default behavior of yarpdev when you open a device, if it detects it has a wrapper, is to load the wrapper as the device, and the device you specified is in fact passed on as the subdevice to the wrapper. In contrast, in a program, if you open() a device, what is opened is... well, the device (with no wrapper): however, if for any reason you want to enforce the yarpdev behavior (not really required, in fact you can always put device/subdevice explicitly, ending up with the same number of lines of code), you can do it via put of the wrapped parameter as seen here.

[drdanz]

I confirm what @jgvictores wrote. The argument in yarp_prepare_plugin ends in a .cpp file used for static libraries, the value in the .ini file is read when the plugin is loaded dynamically.

At some point I was working on removing this duplication, i.e. the .ini file was supposed to be generated automatically. Unfortunately I don't think I finished implementing it...

[traversaro]

Another point in which this concept of "default wrapper" is used is in the DriverCreatorOf class ( http://www.yarp.it/classyarp_1_1dev_1_1DriverCreatorOf.html ) used for adding devices to the factory on the fly.