The new header (as introduced via
2b35c0c28f) was missing a typedef and a
utility macro for dealing with the versioned MumbleAPI struct.
Furthermore, plugins that are only build in debug builds were still
including the old (and now non-existing) headers.
This typedef can be used by plugins that don't want to hard-code the
type of the Mumble API type (which contains the API's version) into
their source code.
If this typedef is used, a newer API can be used simply by including a
different API header.
Instead of excluding all plugins but the link one on OSes other than
Windows and Linux, the new approach allows for a more granular control
by introducing a list of plugins that is supported on the different
platforms.
This replaces the globbing approach which means that new plugins have
now to be included in this list explicitly.
The advantage of this is that this allows for a much greater flexibility
for handling plugins on different OS.
Furthermore the plugin's own directory is no longer added to the
include-path by default. If a plugin wishes to do this, it should do so
explicitly. This should help make the plugins easier to move around in
the future.
There were a few types left that were not prefixed with "Mumble" in one
way or another. In order to avoid name clashes, this was now changed.
Especially enum values are now also prefixed. This is because these are
not enum classes (C doesn't know those) and as such the enum values are
used without a namespace (thus they are effectively global names).
Furthermore the macros STATUS_OK and VERSION_UNKNOWN were turned into
constant variables in order to use the preprocessor as little as
possible.
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes#2455Fixes#2148Fixes#1594Fixes#2051Fixes#3742Fixes#4575Fixes#4751
