LuaRocks and LuaJIT (was Re: ffi.cdef() for module writers)
- From: Hisham <h@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sat, 13 Oct 2012 18:56:36 -0300
On Sat, Oct 13, 2012 at 9:07 AM, steve donovan
<steve.j.donovan@xxxxxxxxx> wrote:
> IHMO, getting a LuaRocks package together is better than trying to aim
> for inclusion in major distros. These all have LuaRocks anyway, and
> it's a lot easier to add new versioned packages to the LR repo than to
> a distro repo, which is important for a fast-developing package.
>
> (LR needs however to have a way of indicating that a package requires
> LuaJIT. If luaffi were in the repos, that could be given as a
> conditional requirement for vanilla Lua)
Thinking out loud, bear with me:
Off the top of my head, there are two ways to go about this.
The simplest way would be to create another repository, say,
rocks-jit, with the LuaJIT-specific rockspecs. LuaRocks running under
LuaJIT would add both repos to its server list and all would be well.
Well, not "all". The asterisks refer to a little real-life
complication if we were trying to offer the largest module selection
to a user according to compatibility. It seems to me we actually have
a little flavors matrix now, if we consider:
Without FFI:
* code that's 5.1, 5.2 and LJ2 compatible
* code that's 5.1 and LJ2 compatible (uses setfenv)
* code that's only 5.2 compatible (uses _ENV)
* code that's 5.2 and LJ2 compatible (uses goto, doesn't use _ENV)
With FFI, multiply the above by:
* code that's only LJ2 compatible (FFI code using NULL==nil)
* code that's only luaffi compatible (is there? any luaffi specifics?)
* code that compromises to be luaffi and LJ2 compatible
(The parenthetical remarks are just examples and are not meant to be a
full list of compat issues, of course. I haven't written any FFI code
yet, so correct me on the above if I'm wrong on any points.)
bitop vs. bit32 is not a showstopper because both are "available for
the other VM" as extra modules; LuaRocks could detect the running VM
and add the appropriate dependency as pre-filled, or fetch the module
on demand.
Som objective questions for which I don't know the answers:
* Does code written for luaffi run unmodified on LuaJIT?
* If the answer is "no", is it be possible to use a subset of both
without "unacceptable" slowdowns for LuaJIT users or at least keep the
ifdef'fing for a minimum? (For 5.1 vs 5.2, for example, I have very
little code in LuaRocks to ifdef around setfenv vs. _ENV; I wonder if
the situation is similar.)
* Do FFI module authors have interest to be friendly to luaffi?
You must have already noticed that what I'm prospecting here is the
feasibility of specifying dependencies as "capabilities" rather than
VM versions, in order to support a larger array of scenarios/users.
The "two repository solution" that segregates by VM and not by
capabilities is less than ideal because luaffi users could be left out
of stuff they could be using because it's luaffi-friendly FFI code and
LuaJIT users could be left out of stuff because it is marked as "Lua
5.2 only" (and that can be, say, either because of goto or because of
_ENV). My question is if it is possible to model such a list of
capabilities that would be a) useful/usable as dependency entries and
b) cover the flavors matrix.
A third way would be to break rockspec compatibility and start using
or-expressions in dependency lists....
-- Hisham
http://hisham.hm/
Other related posts:
