[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: More about packaging (hopefully not too long)
- From: Martin Spernau <martin@...>
- Date: Tue, 08 Jun 2004 11:36:19 +0200
To use a specific example, there is a MIME module in LuaSocket that needs
some C support, but also has Lua code. Thus, there is a mime.dll and a
mime.lua. The user calls
mime = require"mime"
and is happy. In mime.lua, however, I have to load mime.dll. It is good to
be able to do this without worrying about using different names for the C
and the Lua part of the library. I just do
local mime = requirelib("mime")
... define Lua functionality
The implementor *knows* which is which. Why eliminate this freedom?
In LuaCheia we have the cheia.load('mymod') a nd the
The first does only load the Lua stub 'mymod.lua' which the in turn
(may) use cheai.loadmodule('mymod') to load the dll/so, cheia.loadmodule
also figures out the proper filename for the binary module and then uses
loadlib() to actually load it... (which releys on the fact that we have
a entry-point naming convenmtion...)
But ofcourse the Lua/C developer can use any way to actually load the
binary. Glua-X modules e.g. need a different approach. By using
cheia.load() to load a Lua stub this is all in the hands of the developer...
I'm very looking forward to what this discussion will result in!