$darkmode
Elektra 0.11.0
|
resolver_*
, crypto_*
)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 happensPROCESS_DEPS
HANDLE_DEPS
DEPS_MODE
-> too generic, new terminologyCHECK_DEPS
-> not only checking happensDO_DEPS
-> sounds funnyFIND_PACKAGES
-> not only packages are subject to this phaseCOLLECT
-> needs NOTFIND_PHASE
-> needs NOTDEPENDENCY
-> ambiguousIntroduce 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
againADDTESTING_PHASE
.. (reserve for potential 3rd phase)COLLECTION_PHASE
is ON
), add_plugin internally builds up:ADDED_PLUGINS
REMOVED_PLUGINS
ADDED_DIRECTORIES
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 pluginsADDTESTING_PHASE
is ON
), eitherADD_TEST
in add_plugin
, oradd_plugintest
(for unittests that have dependencies to bindings)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:
ADDED_DIRECTORIES
of variants will be kept.