Re: [ANN] mergelua

[David Manura <dm.lua@...>]

On Sat, Oct 15, 2011 at 5:22 PM, Sebastien Lai <237482@googlemail.com> wrote:
> https://github.com/beelzebub/mergelua
> This tool allows merging of (pure, noncompiled) Lua modules into a
> single collective file. [...] Mergelua also features a local override of
> the 'require' function to search the local moduletable first
> [...]
> There are probably a few things that might be tweaked:
>   + minifying of Lua code (removing comments, newlines, etc)
>   + support of bytecode-compiled chunks (unfortunately, I have yet to
> find out how to store the data)
>   + storing of .so / .dll files (same problem as above)

I believe it's preferred to utilize package.preload rather than
override require.  There are a number of utilities like this linked on
the bottom of [1], notably precompiler/preloader, Squish, and
extensions to luac.  Squish handles minifying and compiling byte code
prior to bundling.  Bundling .so/.dll's as well is something some have
also mentioned, like my recent post on the LuaRocks mailing list that
made a comparison to similar things that have been done in Perl PAR
and Java JAR [2].  Your best bet for loading the .so/.dll's from your
bundle is to extract and cache them to a temporary directory (I'm not
aware of it being trivial to do otherwise) and load them into memory
by adjusting package.cpath or calling package.loadlib directly.

I haven't fully analyzed the available solutions though.  My suspicion
has been that string.dump is not as general as it could be [3,4], but
that has been moot on LuaJit which didn't add string.dump support
until recently.  Personally, I just use some combination of scripts
that work for me but are not entirely general.  A real world test of
some bundling tool like this would be to take all the modules in a
distribution (e.g. LuaForWindows/LuaRocks/LuaDist-Batteries), which
are written by many different authors, bundle them into a single file
with your tool, and run all the tests on those packages in the bundle.

I don't see how Lua 5.2-beta's treatment of module negatively weighs
into bundling.  A fundamental part of modularity indeed is
composability, and elimination of side-effects and obscure corner
cases in the module loader function (e.g. even making it pure [5])
furthers that goal.

[1] http://lua-users.org/wiki/BinToCee
[2] http://www.mail-archive.com/luarocks-developers@lists.sourceforge.net/msg00196.html
[3] http://lua-users.org/lists/lua-l/2010-11/msg00898.html
[4] http://lua-users.org/lists/lua-l/2011-07/msg00082.html
[5] http://en.wikipedia.org/wiki/Pure_function