lua-users home
lua-l archive

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

On Thu, Sep 3, 2009 at 9:17 PM, Doug Rogers wrote:
> Each library has to be combed over to
> find which Lua files in the hierarchy are truly part of the install base

This is a problem that LuaRocks is intended to help solve.  It can
help even on a sans-filesystem, static-linking embedded target
unsupported by LuaRocks (LuaRocks and LuaDist have generally been
designed with dynamic linking in mind, but it is not necessarily

Say the library you're interested in is LOOP.  Looking, in
<> you see than LOOP has this
rockspec file:

The rockspec file tells you in a consistent format

  (1) Which files create which modules and what module names
       they correspond to (e.g. "lua/loop/base.lua" creates module "loop.base").
  (2) Which files are not modules (e.g. precompiler.lua and
preloader.lua are applications).
  (3) and other things (e.g. licensing, Lua version compatibility, etc.)

You don't need to run any LuaRocks software.  You may manually compile
given that information or you may write your own tool that
automatically compiles and statically links a subset of LuaRocks
modules into your application via the information in the rockspec
files.  As Steve said:

On Thu, Sep 3, 2009 at 6:02 AM, steve donovan wrote:
> A key insight is that using a data format like rockspec does not bind one to using LuaRocks.

On Thu, Sep 3, 2009 at 9:17 PM, Doug Rogers wrote:
> Doing so with LuaSocket would be a good test. It was very easy for me to do
> so with luaproc....Only when I finished the whole exercise
> did I notice that luaproc.lua did nothing but load the shared object

That luaproc.lua code is unusual, perhaps a pre-5.1 pattern.  I think
LuaSocket would be a better example.  The rockspec for LuaSocket is
more complicated to interpret since its author simply calls out to GNU
make to build a shared library:

Nevertheless, the makefile builds into consistent LuaRocks target
paths, and the assembling instructions are unambiguous (i.e. less
"combing over").  If you prefer CMake over GNU make, instead unzip the
dist --
-- and examine the CMakeLists.txt file.