Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
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):
WITH_XXX | WITHOUT_XXX | plugin XXX supports | result |
---|---|---|---|
OFF | OFF | static builds only | not built |
OFF | ON | static builds only | not built |
ON | OFF | static builds only | built statically |
ON | ON | static builds only | built statically |
OFF | OFF | dynamic builds only | built dynamically |
OFF | ON | dynamic builds only | not built |
ON | OFF | dynamic builds only | built dynamically |
ON | ON | dynamic builds only | not built |
OFF | OFF | both | built dynamically |
OFF | ON | both | not built |
ON | OFF | both | built statically |
ON | ON | both | built statically |
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:
BUILD_PLUGIN_XXX | plugin XXX supports | result |
---|---|---|
STATIC | static builds only | built statically |
DYNAMIC | static builds only | not built |
NO | static builds only | not built |
STATIC | dynamic builds only | built dynamically |
DYNAMIC | dynamic builds only | built dynamically |
NO | dynamic builds only | not built |
STATIC | both | built statically |
DYNAMIC | both | built dynamically |
NO | both | not built |
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.