Add support for the official Lua implementation #225
Conversation
Rename "system_luajit" meson option to "lua_provider" and expand it with support for the official Lua implementation and picking which Lua implementation to use. Bump minimum Meson version to 0.60.0 because we now use a dependency with multiple names (lua52, lua-5.2) which is a 0.60.0 feature.
|
Using normal lua is probably not something I want to support - there's a decade's worth of automation scripts that all assume LuaJIT (and make heavy use of FFI). I'm open to being convinced otherwise, but my default is to avoid breaking the ecosystem, even if I understand it causes more difficulty with packaging. |
|
Your average operating system will either patch out whatever implementation or version you try to force, or refuse to package Aegisub. Most have a blanket rule against baking in dependencies. And few systems want to figure out how to deal with having luajit on 5.1 mode and on 5.2 mode installed at the same time and patch or beg programs to use the right one. Luajit and the Lua language itself provide no mechanism for handling that, so they use 5.1 which is the luajit default and most popular Lua version. e.g. Debian's Aegisub already depends on lua 5.1 or luajit on 5.1 mode: https://salsa.debian.org/debian/aegisub/-/commit/932d99baffaa876a70ee735aea3974ea8cd04d5e https://packages.debian.org/sid/source/aegisub This is another fork that supports using the official Lua implementation (including on 5.1 or 5.3 modes): I'd first worry about making Aegisub compile on more systems and with less trouble on the systems it already supports, any broken scripts can be fixed. Windows and macOS are each far more popular than everything else combined, and over there you control the Lua implementation and version and nothing changes; elsewhere Aegisub either never compiled, or it did for a while but broke in the last 10 years, or the packaged version already uses some unsupported Lua. |
|
In practice, the broken scripts are not going to be fixed. There's too much code that no one really maintains but that sees heavy use. For many of them the maintainer is no longer around, and I'm the only person who can actually commit any changes. I do understand that this situation is awkward for a lot of distros, and will result in workarounds. But hopefully you can have some sympathy for my position here: I don't want to support a known-broken setup. I'm aware that Debian uses 5.1, and this has caused issues historically with people reporting bugs that were not our fault. I'll think on this some more, but I'm not sure what the appropriate compromise is. It seems bad and awkward to merge something like this but still immediately close any tickets from Linux that mention automation scripts, but that's effectively what I'm going to do for any builds not using LuaJIT with the correct configuration. I could also just disable running user automation scripts when running a non-standard Lua config, but that also seems suboptimal. It might be the least-bad option for now, with some kind of pop-up so people understand why it's disabled, but I'm not sure it will work longer-term because I'd like to move more internals over to Lua. I'm open to additional suggestions on what an appropriate balance looks like, but any suggestion that means a gigantic amount of work for me (i.e. updating all existing automation scripts) is a non-starter. |
|
Indeed, Debian patches out the LuaJIT requirement, and as a result almost none of the automation scripts work there: Lua 5.2 is needed, among other reasons, for the |
|
Via https://gitlab.archlinux.org/archlinux/packaging/packages/luajit/-/issues/1, I found https://github.com/lunarmodules/lua-compat-5.3 to be mentioned. It might be an option to run this along with LuaJIT without 5.2 compat, but the fact that it provides 5.3 backports might be problematic and it's also entirely unknown at the moment whether it works or would break a significant portion of existing scripts. |
Currently broken because Aegisub requires Lua 5.2, but uses some Lua 5.1 C library calls which work on luajit because of its loose standards compliance, and break on the official Lua.
The Lua pkg-config file has different names on OpenBSD (lua52) and FreeBSD (lua-5.2), it would be a good idea to see what other systems use in case there are even more names.