Rethink static plugins initialization

[drdanz]

Rationale

• At the moment the YARP_init library has the only goal to load static plugins whenever the network is initialized
• Plugins in other repositories cannot be initialized in the same way as the ones in YARP, therefore it is necessary to write
• Plugins are linked in the yarpcar and yarpmod libraries, which means that even if you want to use static plugins because you have limited resources, you will have all plugins linked, even if you use only one of them, and the compiler cannot remove them, because the symbols are used
• Currently the YARP_init library complicates a lot the CMake part of YARP, and, causes recursive dependencies, and forces weird tricks to make it work.
• Currently, when you enable static plugins, all the dynamic stuff still works, and it is possible to use both static and dynamic plugins. This is quite confusing.
• The reason for having the YARP_init library is unclear to most people, and not easy to explain
• We don't use static plugins, and I'm not aware of anyone who uses them. It's still good to support them, though

Proposal 1
I'd like to change current implementation, by changing current initialization with a manual one, for example something like this:

From:

int main()
{
    yarp::os::Network();
}

find_package(YARP COMPONENTS OS sig dev)
add_executable(foo main.cpp)
target_link_libraries(foo PRIVATE YARP::YARP_OS
                                  YARP::YARP_sig
                                  YARP::YARP_dev
                                  YARP::YARP_init)

To:

int main()
{
    yarp::os::Network();
    YARP_IMPORT_PLUGIN(usbCamera);
// or
    YARP_IMPORT_PLUGIN_COLLECTION(yarpmod);
}

find_package(YARP COMPONENTS OS sig dev usbCamera)
add_executable(foo main.cpp)
target_link_libraries(foo PRIVATE YARP::YARP_OS
                                  YARP::YARP_sig
                                  YARP::YARP_dev
                                  YARP::yarp_usbCamera
                                  # or
                                  YARP::yarpmod)

Pros

• Get rid of the YARP_init library
• Each YARP component will correspond to one library
• no more weird tricks and recursion in CMake

Cons

• This will unfortunately affect whoever is using static plugins
• This will make it impossible to generate an executable that works in the same way with both configurations.
• Wherever the YARP_init is linked explicitly, it needs to be removed, since it will cease to exist (it could become an alias to YARP_OS, though, but there is no way to produce a deprecation warning)
• While this seems quite reasonable with the devices, carriers, that are loaded on demand from other programs, might be problematic since they will not be found.
• It's probably necessary to add a component for each static plugin

Alternatives

• It's probably possible to write some CMake magic function to generate the static plugin initialization function when needed, this could require to modify the CMakeLists.txt file, but not the main, i.e. something like this:

int main()
{
    yarp::os::Network();
}

add_executable(foo main.cpp)
target_link_libraries(foo PRIVATE YARP_OS)
yarp_import_plugin(foo usbCamera)
# or
yarp_import_plugin_collection(foo yarpmod)

The yarp_import_plugin/yarp_import_plugin_collection commands could create a CustomInit.cpp-like file specific for the case, and add it to the sources of the foo target.

This would still require to create one for dynamic only plugins, that's why I don't think it is worth implementing this solution

Proposal 2

When static plugins are enabled, all the dynamic plugin stuff should be disabled, no .ini scanning, no dlopen/dlclose, etc.

[lornat75]

Proposal 2

When static plugins are enabled, all the dynamic plugin stuff should be disabled, no .ini scanning, no dlopen/dlclose, etc.

does this proposal fix all issues? if so, it looks like a good solution

[drdanz]

Probably I did not explain this in the right way, I intended this as 2 separate proposals that fix different issues, both related to static libraries, not different alternatives. This is an easy fix, but the other proposal requires some work...

Unfortunately proposal 2 does not solve a big issue, it is just to fix this point:

• Currently, when you enable static plugins, all the dynamic stuff still works, and it is possible to use both static and dynamic plugins. This is quite confusing.

Also I think that if you want to use static libraries, either you don't have the support for dynamic libraries on the system, or you explicitly want to use static libraries only for some reason. Therefore the dlopen-related stuff should not be there.