Re: Is a Lua system easily embeddable?

[Andre de Leiradella <aleirade@...>]

Fabio Mascarenhas wrote:
> On the other hand, you could compile, let's say, LuaSocket, link the
> .o files in your application, then embed the .lua files along with
> wrapper code that mimicks require'ing them (with lua2c, for example,
> or via resources). Compiling .o files and generating the wrapper code
> could even be somewhat automated from information provided by a
> rockspec that uses the "builtin" LuaRocks build system.

This looks promising.

> If there are utilities to extract object files from .o files you can
> even make your utility work on installed rocks, so you do a "luarocks
> install foo" to install foo and all its dependencies in a rocks tree
> and then run your tool to "staticify" them.
>
> The bottom line is that I think it is easier to go from dynamic
> modules and require, even if it is not perfect, to static embedding
> way than the reverse, specially if you want to have a thriving
> ecosystem of third-party libraries.

Maybe LuaRocks can handle both? You select weather you want a dynamic or 
a static library, and LuaRocks build it for you.

In the case of additional Lua code, LuaRocks could just tell the user 
that they must be handled manually?

Cheers,

Andre

> --
> Fabio Mascarenhas
>
>
> On Sat, Sep 5, 2009 at 3:43 PM, Andre de
> Leiradella<aleirade@sct.microlink.com.br> wrote:
> > KHMan wrote:
> > > [snip]
> > > I'm glad that there are solutions being offered like the Makefile
> > > converter, instead of just yakking and yakking like what I am doing. :-)
> > > What would be really useful right now is some sample implementation of
> > > bundling complex modules that integrates nicely into the original module's
> > > codebase. Then again, the sample solution might be perfect for party X but
> > > party Y might jump up and vehemently disagree. And we'll be back to square
> > > one... :-)
> > I agree with you in that it's impossible to satisfy everyone. But we
> > shouldn't make things hard for any party.
> >
> > I think we can all agree that evolving software is easier then the other way
> > around. Taking a complex piece of software and trying to make it simpler is
> > hard because things get too intricate so removing things without breaking
> > the software requires a great amount of work.
> >
> > Lua is simple, and great and complex things are built on top of it, like
> > i.e. Lua for Windows.
> >
> > Lua modules are complex, and the discussions here in the list proves it's
> > hard to make it simple again.
> >
> > I believe libraries should be simple again. They should compile to static
> > libraries and have a clear indication of its dependencies on both other
> > libraries and additional Lua code required to use it. The developer could
> > then just initialize everything in the proper order to have the final
> > product.
> >
> > On top of that, there could be a build system (LuaRocks?) that can take a
> > library and, by using information provided by it, compile it to a dynamic
> > library that could just be required to be used in the host application.
> >
> > That way, both parties (people that builds monolithic Lua platforms i.e. for
> > embedded devices and people on desktops) will be allowed in the, huh, party.
> >
> > Cheers,
> >
> > Andre