lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Tue, Mar 22, 2011 at 11:06 PM, Alexander Gladysh <> wrote:
> On Wed, Mar 23, 2011 at 04:33, Peter Drahoš <> wrote:
>> On Wed, Mar 23, 2011 at 2:12 AM, Alexander Gladysh <>
>> wrote:
>>> I want to create a rockspec for bindings for an uncommon library
>>> (namely — hiredis: My primary
>>> target is Ubuntu (and compatible OSes). I will not able to support OS
>>> X or Windows deployment for my rockspec.
>>> The library in question is absent in Ubuntu repository, and, thus, is
>>> likely to be missing on user machines.
>>> I can bundle hiredis source code with the rockspec.
>>> However, I do not want to link hiredis statically to my C module —
>>> this does not seem neat enough. And, as far as I remember, Luarocks
>>> would not let me to build a separate
>>> What options do I have?
>> For LuaRocks you should build a static module. It was not designed to handle
>> dependencies on libraries, certainly not in cross platform manner. However
>> this is exactly what LuaDist[1] does well (it builds everything from
>> source).
> While the rockspec and the module would be open-source, I create them
> for my production needs in the first place. I'm not ready to add
> LuaDist as a dependency to my production machines.
> If I will be considering an investment into a change of deployment
> strategy I would rather try switching to Debian packages. LuaRocks
> development is, sadly, too sluggish (no disrespect to the current
> maintainers — this is my problem, not theirs).

No offense taken. Like it was said, if it's practical, linking the
library statically is a fine option for use with LuaRocks. Due to
reasons including our limited development resources, LuaRocks will
stick at what it knows best: being a simple option for building Lua
modules and being a deployment tool for rocks. For environments where
you don't have the luxury of native system packages for external
dependencies, LuaDist is an option for providing external dependencies
in a cross-platform manner.

I don't know if you're set into using either an all-LuaRocks or
all-Debian deployment strategy, but I would consider using LuaRocks
for Lua modules and Debian packages for non-Lua dependencies to be a
sensible strategy.

-- Hisham