We already have infrastructure for multiple flavours of lua ports, so I'd
just use that. If the default lua version is changed we'll need a wider
diff anyway because we'll need to switch from "unflavoured = 5.1" / "lua-XX
prefix = 5.1" to something else, and that will need handling across the
whole tree, so I wouldn't worry about that situation here.
--
Sent from a phone, apologies for poor formatting.
On 17 January 2017 23:56:14 Edd Barrett <e...@theunixzoo.co.uk> wrote:
Hi,
(CCing some people who have worked on lang/lua, hoping one of them knows
the answer to my question below).
This is (yet another) neovim dependency. libmpack (not to be confused
with libmsgpack):
---8<---
libmpack is a small binary serialization/RPC library that implements both the
msgpack and msgpack-rpc specifications.
--->8---
This isn't quite ready as it requires some thought. Neovim (on some
arches) will use this via LuaJIT, not plain Lua. We don't have to do
anything special to build against LuaJIT as plain Lua extensions are
binary compatible with LuaJIT [1].
What I don't think will work is mixing Lua versions. So how do we guard
against the case where (e.g.) the default Lua is bumped to target a
newer Lua than LuaJIT? This means the library will not be found by
LuaJIT.
Although I could explicitly set the Lua version used in this port,
setting it to anything other than the default version seems wrong too,
since then regular Lua users won't have access.
Do we need (versioned) lua flavors, e.g. -lua51, -lua52?
We could just use plain Lua across the board, but that would be a shame.
One of the attractions of neovim is to use a higher performance (and
a less "argh, my eyes, they burn") scripting language than vimscript.
Any ideas, or other comments?
[1] http://luajit.org/extensions.html
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
