Bug#812741: neovim: Please don't build-depend on luajit on unsupported architectures

[James McCoy]

On Mon, Feb 22, 2016 at 02:08:23PM +0100, John Paul Adrian Glaubitz wrote:
> On 02/22/2016 01:05 PM, James McCoy wrote:
> > It's currently possible to build without LuaJIT, as long as you don't
> > want to run tests. However there are plans to embed LuaJIT into neovim.
> 
> The moment they start embedding LuaJIT into neovim, the package needs
> to be patched or it will be removed out of Debian.

That's a bit of an overreaction.  What I meant was what's typically
meant when talking of embedding a language[0][1][2] (especially with
Lua), using the language's functionality from the application.

[0]: https://docs.python.org/3/extending/index.html#embedding-the-cpython-runtime-in-a-larger-application
[1]: https://metacpan.org/pod/perlembed
[2]: http://www.lua.org/manual/5.1/manual.html#3

> > Given that, I don't see it worthwhile to try and workaround the issue.
> > LuaJIT needs to be supported.
> 
> I still don't see what warrants the requirement of LuaJIT in a text
> editor which could not replaced by the regular Lua interpretor.

As I mentioned earlier, LuaC doesn't provide FFI which is something they
apparently want to use.  Also, one of the major purposes they're looking
at for using Lua(JIT) is translating VimL to Lua and then executing
that.  The thought is that using Lua itself instead of LuaJIT would make
that too slow.  Some more information on what has been under discussion
can be seen in <https://github.com/neovim/neovim/issues/801>.

Regardless, I don't see why you're having such a strong reaction to
this.  It's their design choice and just because it limits what
architectures they'll be able to run on it isn't reason enough to
consider this a bug.  There are plenty of applications in Debian which
don't run on all the supported architectures/kernels.

Bram took extreme efforts to keep compatibility with arcane and mostly
unused computers/OSes and that's something the Neovim folks have decided
not to continue, for better or worse.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>