LuaJIT support?
LuaJIT (a lot of uses) is Lua 5.1 syntax and API interface compatible, could sol support it ?
It doesn't seem like LuaJIT is 100% API compatible with Lua 5.2 according to this page. I could be wrong though. If LuaJIT is API compatible with it, i.e. #include <lua.hpp> and all the luaL_* and lua_* functions work as expected then I don't see why it wouldn't support it. However it seems like LuaJIT is 100% 5.1 only with a thin 5.2 compatibility layer.
So could you add the LuaJIT support in sol?
Dropping down to Lua 5.1 would be a massive pain, unfortunately.
I haven't finished building against the latest LuaJIT yet, but they have a flag for 5.2 compatibility that might allow sol to build since we don't make use of _ENV or setenv, which is one of the biggest splits / gripes between the two C APIs.
The more glaring issue, however, is that it seems like LuaJIT doesn't support GC on tables, only on userdata and friends. All of the magic we do in sol to make sure there's no memory leaks is predicated on user data, but I'd need to go through the codebase to make sure we don't end up in the situation displayed here.
The compiler errors say that we would need to figure out the Lua 5.1 equivalents of the following:
lua_tounsigned
luaL_setfuncs
luaL_requiref
lua_rawlen
unsigned, we can replace with a raw cast to unsigned from double (hacky, but it will work just fine).
luaL_setfuncs is somewhat replacable by luaL_openlibs (I think)
luaL_requiref, I'm not sure what the analogous is there... (@Rapptz, any ideas?)
lua_rawlen, we can probably swap out for a less useful length function that invokes metamethods (lua_objlen, lua_len)
The following built-in libraries would be missing and thus unopenable for lua:
bit32 -- luaopen_bit32
coroutines -- luaopen_coroutine
LuaJIT has the first one built on, so that should be #ifdef'd out, and the second one can be replaced by Coco, but quite honestly I would rather just #ifdef that one out as well and let users manually pick the library of their choice to require and use with lua.
We'd also need to figure out how to replace LUA_RIDX_GLOBALS for luajit to be happy with getting the global table (is this what _ENV was for?).
Ultimately, however, my recommendation would be to wait for Mike Pall to update LuaJIT to work with 5.2 and upcoming 5.3.
If you are really interested in supporting 5.1, I would suggest looking into the compatability files for lua-intf by @SteveKChiu. Specifically, this and this.
@SkyMarshal @happen23 This took a while, but the pull requests referencing this issue has LuaJIT 5.1 support. Once it's evaluated by @Rapptz it should be good to go.
Good luck.