Re: Binary Modules for Lua [was Re: External modules]

["Martin Spernau" <martin@...>]

I was thinking about a (simple) way to do this 'fat or dynamic' thing you
describe.
Currently I 'simply' add the needed code for loadmodule (two functions) to
the module main code and build as a dll (simple to set up in VC).

Maybe instead writing a (realy short) 'wrapper' for each module that defines
both luaLM_import() and luaLM_version for the specific module and setting up
distinct 'Projects' for a) the module.lib (VC for compiled lib) and the
loadmodule ready dll (which statically links the module .lib) could be a
way.

Additional to the loadmodule enabled dynamic linking lua.exe there would
then be need for a statically linking lua.exe, which does all the required
lua_*open() calls for each lib itself.

I could supply VC projectfiles and sources for such a thing, but I'm not
very experienced so I don't know how good they'd be.

My current list of modules:
LuaSocket (1.4)
lxp (expat binding)
zlib (using code from the lux project)
packlib
luaSQLite (embedded DB/SQL engine, no need for external DB deamon etc.)
and my 'own' luaFuzzy

I'm also working on a binding to PCRE, but that will still take some work as
my C-skills are 'novice' level ;) (But thanks to all this I'm learning fast)

I'm fairly sure such a list could also be compiled for Linux/*ix, but I
can't help there, as I have very little experience with Makefile building
etc. for Unix platforms.

-Martin


>From: "Björn De Meyer" <bjorn.demeyer@pandora.be>
>Martin Spernau wrote:
>>
>/snip
>> Well, this is coming along real nice I think. As soon as we can put
together
>> a nice little list with all or most of the commonly used Lua extensions,
I
>> do think this should have some greater use for a lot of people...
>>
>> -Martin
>
>I think we most definitely need a lislike this. Also,
>I think these extensions should also be able to be compiled in
>statically as wel as dynamically, if that is possible.
>We would need a "fat" Lua distribution, based on the
>officila lua, together with all modules that are
>more or less portable. The "fat" Lua could then be geared
>more towards standalone use, whilst the "official" lua
>remains focused on embedded use.