Currently cmake uses WITH_XXX, WITHOUT_XXX, WITH_XXX_STORAGE_ENGINE, WITHOUT_XXX_STORAGE_ENGINE to specify what plugins should be compiled and how. They are

• mixed in the GUI with WITH_PCRE, WITH_JEMALLOC, WITH_PIC, and the such, plugin variables are not easy to spot
• redundant and confusing, one can have any subset (including empty) of WITH_XXX, WITHOUT_XXX, WITH_XXX_STORAGE_ENGINE, WITHOUT_XXX_STORAGE_ENGINE defined, it's not immediately clear what the behavior is in these cases
• they do not necessarily exist in a GUI, some of them are. E.g to disable innodb one needs to do cmake -DWITHOUT_INNOBASE=1 (creating the option), one cannot do it in a GUI, because there is no WITHOUT_INNOBASE option to change)

This is the current behavior (ignoring *_STORAGE_ENGINE variants):

In this task we implement a set of BUILD_PLUGIN_XXX options:

• they will sort in a distinct group, all together, not intermixed with other non-plugin options
• the values will be STATIC, DYNAMIC, NO, which (hopefully) clearly specifies whether a plugin will be built and how.
• WITH_XXX, WITHOUT_XXX, etc values are recognized (if defined on the command line) and work as before, but they are never set in our cmake files, so they never show up in a GUI.

This is the new behavior:

Thus BUILD_PLUGIN_XXX can be explained as «the highest desired plugin integration level». For example, if it is set to STATIC, but plugin does not support static builds — okay, it'll be built dynamically. But if we want at most DYNAMIC integration level and the plugin only supports static, it will not be built at all.