This introduces two concepts: a plugin and its loader (library)
LO currrently has dependency cycles for some libraries. There is
scui, which depends on sc, while sc dlopen's scui. There are the
various vclplug_*, i18npool plugins, filters/gie, acc, etc.
Usually these plugins link to their loader library, because they
use its symbols. But as a result there is no sensible way to
express the runtime dependency of loaders on the plugins.
In GNU libtool plugins are called modules and they are implemented
in an IMHO more sensible way by allowing missing symbols at link
time. This way you can have a dependency from the loader library
to its plugins, as the plugins don't depend on the loader, but you
lose the link time detection of missing symbols.
While this is in theory possible in LO too, LO currently has
plugins, like acc (accessibility), loaded by tk (toolkit), which
depends on svt (svtools), which itself depends on tk, so dropping
the tk dependency for acc on its own doesn't help :-(
And while the dependency of the plugins on their loader is fine
for the shared / DYNLOADING build, for the "static" builds you
must (somehow) link the plugins into the executables.
I also codeified a few rules into the build system along with it:
* just plugins are allowed to depend / link other plugins
* plugins aren't allowed to be linked into the merge lib
* plugin loaders are "limited" to libraries
At the high level, this is implemented via new gbuild calls:
* gb_Library_set_plugin_for,lib,loader: declare a library to be a
plugin of a loader library and add a dependeny from the plugin
library to the loader library
* gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding
the library dependeny
* gb_Helper_register_plugins_for_install: "plugin" replacement for
gb_Helper_register_libraries_for_install to implement some
additional checks in the build system
In the end this patch just adds a bit syntactic sugar and nothing
changes for any build.
Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
ed583bf8d5