On 12 November 2013 08:47, Justin Cormack <jus...@specialbusservice.com> wrote: > On Tue, Nov 12, 2013 at 12:45 AM, Hisham <h...@hisham.hm> wrote: >> On 11 November 2013 19:45, Justin Cormack <jus...@specialbusservice.com> >> wrote: >>> On Sun, Sep 29, 2013 at 3:46 PM, Justin Cormack >>> <jus...@specialbusservice.com> wrote: >>>> (moving to luarocks list) >>>> >>>> On Sun, Sep 29, 2013 at 2:59 AM, Hisham <h...@hisham.hm> wrote: >>>>> * there are no (AFAIK) modules that are LuaJIT-only in the main rocks >>>>> server. Nothing stops one from making an alternative rocks server with >>>>> LuaJIT-only rocks. If there is demand I could host that at >>>>> luarocks.org too, but I don't recall receiving any rockspecs for >>>>> ffi-based rocks, even though they were never disencouraged. >>>>> * there is a magic dependency "lua" you can use in your rocks to >>>>> specify 5.1 and/or 5.2, but there is no "luajit" magic dep (this could >>>>> be added), nor a way to say "lua ~> 5.2 or luajit ~> 2" (this can't be >>>>> added right now because it's new syntax and would break rockspec >>>>> compatibility). >>>>> * even though LuaJIT presents itself as Lua 5.1, it has as you said >>>>> partial 5.2 compatibility, so there are probably rocks that require >>>>> "lua ~> 5.2" and would work on LuaJIT, but LR doesn't know about that >>>>> (and figuring out which rocks are LuaJIT-compatible is not reliably >>>>> automatable). >>>>> >>>>> I'd be happy to make any necessary adaptations to make LR play well >>>>> with LuaJIT, if there's interest, but I haven't heard much about >>>>> LuaJIT in the LuaRocks mailing list. >>>> >>>> Its a bit chicken-egg, havent submitted anything as at least having a >>>> a luajit magic dep is necessary first. I wouldnt worry about the 5.2 >>>> nuances at present. >>>> >>>> Longer term, there is the issue about how to deal with packages that >>>> might have a different dependency set if under LuaJIT or Lua, eg can >>>> use libffi for compatibility, or uses another dependency. This can be >>>> ignored as worst case is you build/install the extra dependency but >>>> dont use it at runtime. >>> >>> Any further thoughts on this? It seems the options are to (a) split >>> the repos between luajit only and lua (which might mean some things >>> get two rockspecs) (b) add at least some knowledge of luajit to rocks >>> or (c) status quo rocks is just for PUC Lua or things that work on >>> both. >> >> I'd like (b) to happen, but (a) is compatible with older versions of >> LuaRocks (which distros may still be shipping). Alternatively, we >> could do (b) by providing a "luajit" virtual dependency like we >> currently do with "lua", but also provide a dummy luajit rockspec >> which users stuck with older versions of LuaRocks could install only >> to satisfy the virtual dependency (not in the main repo to avoid >> confusion with users trying to run `luarocks install luajit`). >> >> This issue is related: >> https://github.com/keplerproject/luarocks/issues/177 > > Yes, that issue suggests a fourth way, where luajit provides "ffi", > "bit", which can also be provided by "luaffi" or "bitops", lua5.2 > provides "bit32" and so on (or more granular, my app needs "bit" or > "bit32", "luaffi" or "ffi"). You then need to know whats installed.
But AFAIK luaffi is not 100% compatible with the LuaJIT FFI, nor the other way around (as I understand there's a compatible subset but neither API fully covers the other one)... am I correct? In that case providing a generic "ffi" virtual dependency is probably asking for later trouble... -- Hisham ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
