On Sun, Mar 1, 2015 at 9:45 AM, Vadim A. Misbakh-Soloviov <m...@mva.name> wrote: > В письме от Вс, 1 марта 2015 20:36:03 пользователь Ben de Groot написал: >> >> Or maybe one of the other lua package maintainers has plans? > > > Not that I'm in-tree lua maintainer, but as Lua-overlay contributor and lua- > fanboy, I'd suggest to unmask all lua-interpreters and make them slotted just > as python/ruby/whatever. And provide a eselect-lua (I had ebuild for it > somewhere).
This isn't going to happen any time soon, for several reasons. :( > Although, there is single issue: precompiled bytecode isn't compatible between > even "5.1" PUC-Rio Lua and LuaJIT, and, of course, AFAIR, between Lua5 > releases. You explained why yourself. This issue can be solved doing something like what is done for python, compiling and installing bytecode for each interpreter, but unless someone implements this perfectly, at least luajit isn't going to be involved in such thing. > But I don't think Lua-users do not know about that, so I don't think it is a > real problem. No, this is a real problem to implement multi-interpreter support. They don't care about the issue because they don't care about supporting other interpreters, or even multiple versions of Lua installed in parallel. I'm going to repeat this once again: Lua was designed to be built statically, then upstream don't cares about compatibility between different versions and interpreters. Creating static libraries is something that distributions want (and is generally the best approach), but the upstream developers don't care about this at all. That said, if you want to go that way, you are in your own, upstream isn't going to care about your issues or make your life easier. []'s -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/