The other thread got out of hand and was closed, so here is a new one to keep you up to date on my progress on my attempt to automate the Lua binding generation.
(This is not an exhaustive list)
luaaa: The first library I found for the task, which seemed very similar to pybind11 in syntax and thus a good candidate. However, it seems to possibly be missing basic features that would be required for Urho like supporting class inheritance. If the author gets back to me about how it works maybe it is actually viable.
LuaBridge: Seems like a more complete version of what luaaa was aiming for, and has recent (2 months old) activity. Also somewhat similar to pybind11 in syntax, and seemingly simpler to set up than some of the others. It’s features include:
- MIT Licensed, no usage restrictions!
- Headers-only: No Makefile, no .cpp files, just one
- Simple, light, and nothing else needed (like Boost).
- No macros, settings, or configuration scripts needed.
- Supports different object lifetime management models.
- Convenient, type-safe access to the Lua stack.
- Automatic function parameter type binding.
- Easy access to Lua objects like tables and functions.
- Written in a clear and easy to debug style.
- C++11 compliant
However, it has a few things that aren’t supported that might be important to Urho:
- Enumerated constants
- More than 8 parameters on a function or method (although this can be increased by adding more
- Overloaded functions, methods, or constructors. (May be annoying to use, but should be doable with adding some decoration to the names like c code, and may not differ from how it is presently)
- Global variables (variables must be wrapped in a named scope).
- Inheriting Lua classes from C++ classes. (ScriptObject may become more complicated?)
- Passing nil to a C++ function that expects a pointer or reference. (Note, the documentation later makes it seem that nil gets converted to nullptr for functions expecting a pointer, so I’m not sure that this is correct)
- Standard containers like
std::shared_ptr. (Note, it supoprts different object management models like an intrusive ref-counted pointer with custom container types, so this should actually be fine for us)
- Overloaded free functions
- C++ classes in Lua
- Overloaded member functions
- Lua functions in C++
- Lua classes in C++
- Lua classes (single inheritance)
- Derives from Lua or C++ classes
- Override virtual functions from C++ classes
- Implicit casts between registered types
- Best match signature matching
- Return value policies and parameter policies
OOLua: Seems the last updates were ~9 years ago and the wiki was on GoogleCode and no longer exists. As such I’ll probably stick with one of the above options instead, even though “OOLua slightly outperforms LuaBridge in some tests”.
tolua++: Urho’s current solution. I don’t plan on using it, as generating pseudo-header files to have a tool generate the binding code sounds a lot more difficult than some of the other options. I also think that it is no longer maintained, though I’m not sure on that point.
Currently I’m planning on trying LuaBridge, with it’s easier setup and seemingly more recent maintenance. If I find that too limiting, I’ll probably switch to one of the LuaBind forks with more recent work (e.g. one that switched to CMake).
The basic roadmap would be:
- Simple test project evaluating the library like I did with Luaaa to see limitations like not supporting inheritance and how to do the container types and such.
- Generating bindings, probably starting with the Math subfolder (no SharedPtr’s to deal with, and I can test operator handling). Then extend it to support the Container types (String, Vector, HashMap, Variant) and the Core types (Context and Object mainly). Some simple test files would be involved here.
- Generate bindings for all of the classes and test the existing samples.
- If the samples need to be rewritten someone else will have to step up unless it’s some find+replace type changes, as I am not committed enough to Lua to hand-edit 50 programs. I’ll handle a few to test (e.g. Hello World, Physics Stress Test), but I don’t think I’ll be motivated to finish all 50 if they involve significant changes. Hopefully they don’t, and there aren’t too many areas where the current manual bindings would differ from the automatic ones.
As a heads up, note that I may choose to use python to generate the bindings, as I find it a lot quicker to work with than C++. Or I may stick with C++ given the excellent work done making the AngelScript binding generator, we’ll see. Or a mix of both using cog.