Issue
- Plugin names and plugin folders not always exactly match (resolver_*, crypto_*)
- plugin should be able to register new variants
- there should be only one place to define a new plugin
- Multiple categories should be possible per plugin, defined in README.md
- On some OS some plugins won't work (simpleini)
- Some unit tests depend on bindings
Constraints
- should work with supported cmake
- It should be easy to add trivial plugins (without dependency and variants)
- It should be possible to add complex plugins (with dependencies on plugins/unit tests and many variants)
Assumptions
Considered Alternatives
- have one more mapping that describes folder <-> plugins (bad coherence)
- directly use README.md to also describe cmake deps (too limited in expression)
- split up AddPlugin.cmake and CMakeLists.txt (does not work well with variants)
- simply adding all directories in src/plugins and decide within the
add_plugin
if we should drop the plugin (see below in Argument)
Names for flag:
DEPENDENCIES
-> might be used for add_plugin
ASSEMBLE_DEPS
FIND_DEPS
-> not only finding happens
PROCESS_DEPS
HANDLE_DEPS
DEPS_MODE
-> too generic, new terminology
CHECK_DEPS
-> not only checking happens
DO_DEPS
-> sounds funny
FIND_PACKAGES
-> not only packages are subject to this phase
COLLECT
-> needs NOT
FIND_PHASE
-> needs NOT
DEPENDENCY
-> ambiguous
Decision
Introduce a cmake process where all plugins are processed three times. Following cmake variables are used for the phases:
COLLECTION_PHASE
.. collect all add_plugins
DEPENDENCY_PHASE
.. resolve all dependencies, do add_plugins
again
ADDTESTING_PHASE
.. (reserve for potential 3rd phase)
1.) Collection phase (COLLECTION_PHASE
is ON
), add_plugin internally builds up:
ADDED_PLUGINS
REMOVED_PLUGINS
ADDED_DIRECTORIES
2.) assemble dependency phase (DEPENDENCY_PHASE
is ON
, only considering ADDED_DIRECTORIES
), with:
- find_libraries, actually search for libraries on the system (only relevant libraries of plugins that are considered for inclusion)
- add_plugin, with actually adding the plugins 3.) assemble all unit tests (
ADDTESTING_PHASE
is ON
), either
- with
ADD_TEST
in add_plugin
, or
- with
add_plugintest
(for unittests that have dependencies to bindings)
Argument
Solves all the issues without adding too much complexity for actually adding plugins.
Maintaining additional mappings is very time-consuming. Simply adding all plugins directories is problematic. It would:
- clutter the cmake output (especially in the case of errors)
- introduce more variables into the CMakeCache which are irrelevant for the user
- maybe even find libraries in wrong versions which are incompatible to what other plugins need
Implications
- need to adopt all CMakeLists.txt
Related decisions
Notes
Limitations
ADDED_DIRECTORIES
of variants will be kept
- Typos in plugin names are currently not checked, strings that are not plugin names are simply ignored.