Elektra: CMake Plugins

Elektra 0.8.24

CMake Plugins

## Problem

- 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 Rationale)

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)

## Rationale

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.