Switch to cmake and mumble-plugin-cpp, also OO rewrite

[hbeni]

Robert adviced us:

I once again advise you to rework your plugin so it uses https://github.com/mumble-voip/mumble-plugin-cpp as a base. When using the cpp based API, memory management is automated and you never have to worry about it.

Additionally: We should refactor to use more OO structures to get rid of all the global variables and functions (ref #58)

[mill-j]

@hbeni I'm willing to invest some time on figuring this API out and maybe rewriting the plugin. From the little I've seen it looks a little more like what I'm used to working with. And I have a feeling it should be easier to maintain.

I haven't used cmake on any of my projects yet, but if we do switch, let's make sure we can parallel build ;) Currently make -j4 fails. Not a big deal on such a small project though.

So what do you say we keep the current codebase patched and in working order and work on the new one on the side till it's a seamless drop-in replacement?

[hbeni]

So what do you say we keep the current codebase patched and in working order and work on the new one on the side till it's a seamless drop-in replacement?

Good idea!
regarding cmake; i'm not sure if the switch is really needed for using the cpp-plugin interface. It would be good, however i have no idea of cmake yet.

[Krzmbrzl]

regarding cmake; i'm not sure if the switch is really needed for using the cpp-plugin interface. It would be good, however i have no idea of cmake yet.

Strictly speaking it is not a requirement for using the wrapper. However all its dependencies and all the internal macro-management is done via cmake. So if you chose to use it in a different way, then that would
a) be unsupported by me
b) be a bit of work to get all the functionality cmake currently does into whatever other system you are using.

[hbeni]

@mill-j It would also be cool to convert the radio code and other modules to objectoriented, btw.

[mill-j]

Certainly, that should be easier than the current structs. Not to mention much easier to document with doxygen. What do you want to call the new branch?

[hbeni]

Pick your name - I usually do include the issue number tough.
Maybe Issue-82_OORwrite. Whatever you choose.