Re: Proposal: smartlua

[steve donovan <steve.j.donovan@...>]

On Thu, Mar 7, 2013 at 2:14 PM, Peter Drahoš <drahosp@gmail.com> wrote:
> Licensing on some dependencies does not allow for static linking to the library and therefore forces the project to use multiple files

Yes, if by 'distribution' you mean 'make public'.  If a person makes a
personal single executable for their own purposes on their own
machines, then even the GPL is fine.  If the tools make this easy,
then I'm sure people will enjoy the convenience of creating a single
image that does a single job, at the cost of some repetition and disk
space wastage.

> Another issue is packing of application data that projects using smart lua would use .. again resulting in multiple files.

I've tended to get around this issue by making application data in the
form of Lua files (like style sheets as Lua modules which just return
a big string).  That's a useful trick for LuaRocks deployment, where
it isn't so easy to find out where a project's extra files are.  Then
it's just another Lua dependency to be packed by soar.  OK, this isn't
very efficient for binary data, although there are ways and means.  I
can envisage a rather simple extension of srlua where these files are
archived in the executable after the Lua source chunk.

> The primary motivation for smartlua should be ease of use with high degree of automation and minimal pain for the user.

There we totally agree; monolithic executables are just a tactic
towards that strategic goal.  There's something attractive about the
idea of a Lua program being packaged as a zipped archive, rather as
Java programs are packaged.  And (unlike the jar format) that could
include binary extensions.

I think the thing to do is to throw the question back, and ask: what
would be easy? what would be the workflow?  And let the engineering
work around that.  It _is_ an important thing for a language, because
I see my colleagues struggling to pack their beautiful Python scripts
into programs that they can actually give to someone else ;)

steve d.