Cross platform C++ plugins by supplying source code

[FakeTruth]

This is just a small thought I had, which might be somewhat interesting.

How about we add support for native cross platform plugins in MCServer by supplying the source code of these plugins rather than the compiled binary form?

Apparently MSBuild (the building and compiling software used by Visual Studio) is free to use and does not require Visual Studio to be installed. Maybe the MSBuild tool can be distributed along with Windows builds of MCServer, or make it an optional prerequisite for using native plugins in MCServer. http://www.microsoft.com/en-us/download/...x?id=40760

AFAIK most Linux distributions also come with a compiler, and if it does not, it's easy to install by using package managers and such.

MCServer can compile the files in a plugin folder itself by using the build tools and then dynamically link with the plugins, thus not requiring the developer to supply builds for each platform. For developers MCServer can also dynamically reload native plugins without restarting the server, much like scripts, for faster iterations.

MCServer could poll and grab new versions of plugins from GitHub if they're hosted there and recompile them at any time.

Just an idea, of course this does not need to be implemented. But would definitely make a fun and interesting little project.

[bearbin]

It would be cool, but almost impossible to do with no fuss to the user.

I don't think there's much need for it anyway, as lua is pretty fast. If you wanted more speed, the easy thing to do would just be to plug in LuaJIT.

The GitHub idea is great, no matter what plugin system we use. The only thing that's blocking that though is networking support for plugins.

[worktycho]

One significant issue with doing this is dynamically linking the plugins. The executable would have to be re-linked or we would have to manually load the dynamic library's, using OS specific APIs. Also due to the fact that most platforms do not have a standard C++ ABI, the interface would have to be in C with a C++ wrapper in the plugin.

[FakeTruth]

It would be cool, but almost impossible to do with no fuss to the user.

I don't think there's much need for it anyway, as lua is pretty fast. If you wanted more speed, the easy thing to do would just be to plug in LuaJIT.

I know, just for the sake of coming up with ideas I did not list the difficult/negative parts.

One significant issue with doing this is dynamically linking the plugins. The executable would have to be re-linked or we would have to manually load the dynamic library's, using OS specific APIs. Also due to the fact that most platforms do not have a standard C++ ABI, the interface would have to be in C with a C++ wrapper in the plugin.

I am talking about dynamic linking yes, not static. I don't see how this is a significant issue. It's easy to overcome. Plugins would only need a single C interface function, or maybe two if you want to add a backwards compatible versioning system of the plugin API.

[xoft]

Even with dynamic linking things are not that simple. You can't reliably pass objects across dll boundaries, because different compilers (and different compiler versions) have different ideas about the object's internal structure. For example there's no guarantee that the object's virtual table will be at the assumed address. No, believe me, C++ dll interface is hell, we've been there at work and it's just not reliable enough.

So we need a C interface, which means writing tons of glue code yet again. And there's not much advantage that it would offer; the only thing C/C++ is better at than Lua is speed, and there isn't a speed issue with any plugin at all currently (apart from choosing obviously bad algorithms, of course). And even if there was a speed issue, it could still be solved by pushing the critical calculation to C++ and accessing it via the Lua API, as is done with for example the cBlockArea merging.

[worktycho]

Its significant because we need to add code to load the library and init the plugin. When Initializing the the plugin we need to pass in a list of callbacks so that the plugin can call API functions. All of the callbacks would have to point to thunks with C calling conventions.

[FakeTruth]

Does that apply to Windows as well, or just Linux compilers? Because it seems easy enough to use the appropriate compiler and settings for Windows...

You guys are great at cracking down ideas

[worktycho]

You've still got the issue with libraries linking to methods in the parent executable. The linking models just don't allow that, so the methods the plugins called would have to be duplicated in the plugins and only pass data back and fourth. However you on windows you could just use in-process COM which we are well on the way to reinventing on this thread.

[FakeTruth]

I don't understand. Aren't the MCServer headers enough for the plugins to call functions? Just pass cRoot along once in the initialize function and it should have full access to everything right?

EDIT:
Okay nevermind, apparently it doesn't work like that..

[FakeTruth]

Ah, we could compile MCServer into a DLL, supply the .lib and link it with that That works...