I also thought about maybe using LLVM IR.
However I don't know / don't think it will work well with different platforms without an insane amount of work to be done.
I don't know how relevant it is for the IR to be generated for a certain platform / what gcc or clang really tweaks for optimization.
Google has done something similar by declaring their own ABI for use with their VM:
https://developer.chrome.com/native-client
If we had something like this people could use whatever language they like as soon as there is a compiler that can generate LLVM IR (for our ABI), afaik (I didn't dig deep enough into that, so I can't guarantee anything).
This would however require to run a VM (and somewhat defeats the purpose) however we'd have increased security by sandboxing (so unlike native code this could not also load other stuff that is not part of Cuberite) and I think using a custom ABI and VM object passing shouldn't be a problem either.
EDIT: See here: http://stackoverflow.com/questions/14258...s-platform
EDIT2: Also if someone really would have enough spare time and will he could probably force generation of portable LLVM IR or bytecode for an own VM using sdcc which uses newlib to provide necessary functions. But this would enable only C and not C++.
EDIT3: I think the best way to distribute plugins is by letting people build them from source in a unified way, similar to source packages in Linux distros, where you can just do a rebuild of the plugin for the architecture you want. So I think distributing packages which include the source code together with build and install scripts is the best solution.
However I don't know / don't think it will work well with different platforms without an insane amount of work to be done.
I don't know how relevant it is for the IR to be generated for a certain platform / what gcc or clang really tweaks for optimization.
Google has done something similar by declaring their own ABI for use with their VM:
https://developer.chrome.com/native-client
If we had something like this people could use whatever language they like as soon as there is a compiler that can generate LLVM IR (for our ABI), afaik (I didn't dig deep enough into that, so I can't guarantee anything).
This would however require to run a VM (and somewhat defeats the purpose) however we'd have increased security by sandboxing (so unlike native code this could not also load other stuff that is not part of Cuberite) and I think using a custom ABI and VM object passing shouldn't be a problem either.
EDIT: See here: http://stackoverflow.com/questions/14258...s-platform
EDIT2: Also if someone really would have enough spare time and will he could probably force generation of portable LLVM IR or bytecode for an own VM using sdcc which uses newlib to provide necessary functions. But this would enable only C and not C++.
EDIT3: I think the best way to distribute plugins is by letting people build them from source in a unified way, similar to source packages in Linux distros, where you can just do a rebuild of the plugin for the architecture you want. So I think distributing packages which include the source code together with build and install scripts is the best solution.