I talked about this in a different thread, but how wise is it to update Lua?
Advantages
Disadvantages- Parts of more advanced plugins may break
- Is tolua++ compliant?
- Is the lua API same enough for our purposes?
- More?
The Lua's C API has changed a bit, too, and we'd need someone to actually evaluate whether those changes break anything or not.
With my extensive knowledge of the Lua C API (/sarcasm) I managed to make it compile, but it crashes directly afterwards :| I also had to do allot of things manualy copying a x86 version of tolua++ so that Visual Studio would actualy continue compiling.
I'd say that if we are going to update lua we should also look at replacing tolua++. At the moment we basically have to maintain it ourselves and it is not setup to handle more modern c++. Updating lua would necessitate that we rewrote the library and I suspect it would be less work to just replace it.
Unfortunately there isn't much that could replace it that uses a similar style of parsing headers so I suspect the easiest option would be to use a template based library like
https://github.com/SteveKChiu/lua-intf . Transferring would be tough but I suspect the APIDump plugin could be used to generate the initial definition files.
There's one feature of ToLua that will be quite difficult to achieve in other libraries: overloaded functions. We use that mostly for constructors (cItem()), but for normal functions as well (cEntity:SetSpeed()). I haven't found any info in lua-intf about whether it supports overloads or not, I suspect it doesn't.
EDIT: I've looked through the lua-intf code and I'm now pretty sure it doesn't support overloads.
I forgot to check that and by the looks of that library doesn't support it. That causes problems as I couldn't find a library that meets all our criteria so we would have to build our own or modify an existing library. The template approach has trouble with overloads but it might be feasible to modify a template library to support it. Otherwise we might want to take something like SWIG and add support for lua 5.3, though SWIG in particular has some license issues that would cause problems with our current library distribution approach.
Well for a start we'd have to patch tolua's libs, as it depends on LUA_GLOBALSINDEX which was removed in 5.2. So we'd be completely supporting our own version of tolua. So how do people feel about maintaining a c++ parser
.
Why don't we export the plugin interface for plugins written in c++? The loader would then take dynamic libraries and execute the code inside.
Because if I want to create a plugin I don't want to compile it for Windows, Linux, Linux ARM, etc.