lua-users home
lua-l archive

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




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