[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ann] Blog post on Luvit without Luvit
- From: Hisham <h@...>
- Date: Tue, 26 Apr 2016 08:24:33 -0300
On 25 April 2016 at 11:33, Ryan Pusztai <email@example.com> wrote:
> On Sun, Apr 24, 2016 at 9:24 PM, Tim Caswell <firstname.lastname@example.org> wrote:
>> > Also why did we need LuaBitOpts installed. It is not used in any of the
>> > examples? If it is a dependency for luv why not include that in your
>> > LuaRocks dependency list?
>> Again most luvit modules are written for luvit, which means luajit where
>> the bit library is a built-in. But in this example we were using plain lua
>> so we needed to add the bitop library manually on the luarocks side so that
>> it would be compatible. It's not listed as a dependency since it's part of
>> luajit normally.
> Hum I wish this could be automatic in LuaRocks. Does it hurt LuaJit to have
> LuaBitOpts installed? If not, I suggest adding it to the LuaRocks this way
> it will work always. This is just my personal forgetful selfs opinion, but
> the framework looks so good I want everyone to have success.
Since LuaRocks 2.1.2 (jan 2014), when LuaRocks is running under
LuaJIT, the "luabitop" dependency is assumed to be already installed.
So writing "luabitop" in the dependencies section of a rockspec means
that it will be installed when running in Lua, but it is a no-op in
Similarly, the "bit32" and "utf8" dependencies are assumed to be
installed if they are built in the interpreter, but can be fetched as
a rockspec in Lua installations when they are not. (There are
backports of the built-in Lua modules from Lua 5.2/5.3 in the LuaRocks
repository that load fine in Lua 5.1/LuaJIT).