[pkg-lua-devel] LuaJIT package.path?

[Peter Colberg]

On Sat, Oct 19, 2013 at 01:43:19PM +0200, Enrico Tassi wrote:
> Mike's answer was suggesting to put them in the lua/5.1 directory.
> It is ugly one could require these modules from a stock lua5.1, but
> it would get an error like "module ffi not found".
> 
> One could also patch the various modules using ffi introducing a line
> like this one:
> 
>   ffi = assert(require'ffi', 'This lua module works only with luajit')
> 
> That would make the "solution" proposed by Mike less ugly.

If the binary packages are named luajit-<module>{-dev}, then this
explicit notice would not be needed, right? Can I help with adapting
dh-lua to support this scenario?

> There is another thing to take in to account.
> There is an almost complete implementation of ffi for stock lua.
> BTW, have you tried it on your modules?

Yes; there are numerous problems with luaffi.

 * It does not support pointers to arrays (needed for MPI) [1].

   [1] https://github.com/jmckaskill/luaffi/issues/59

 * It does not support certain alignments (needed for OpenCL) [2].

   [2] https://github.com/jmckaskill/luaffi/issues/60

 * It does not support parametrized types [3]. This is needed to
   acquire a pointer to a generic cdata object.

   [3] https://github.com/jmckaskill/luaffi/issues/46

 * It does not support comparison of pointers to nil. The work around
   is a compatibility layer using ffi.C.NULL.

 * It does not implicitly convert C integers to Lua numbers. This
   requires always using tonumber() for compatibility.

So the first three points need to be fixed in luaffi, and the latter
two need to be fixed in every module modules using the FFI.

If luaffi was portable to platforms other than those supported by
LuaJIT, that would be worthwhile; but currently it supports only (a
subset of) the platforms supported by LuaJIT; on those platforms, it
makes almost no sense not to use LuaJIT instead. I suggested to use
libffi [4, 5] for better portability, but I don't know whether this is
feasible.

[4] http://sourceware.org/libffi/
[5] https://github.com/jmckaskill/luaffi/issues/61

Regards,
Peter