[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Adding module+DLL to Lua for Windows (LfW)
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Thu, 10 Dec 2009 17:37:17 +0100
2009/12/10 Joshua Jensen <jjensen@workspacewhiz.com>:
> ----- Original Message -----
> From: steve donovan
> Date: 12/9/2009 5:02 AM
>>
>> On another note, the Windows .dll model is irritating because an
>> extension must be compiled to link against a specific .dll, unlike
>> with Unix where the extension finds its dependencies dynamically from
>> its link context. This makes it trivial to have both luajit and lua
>> executables together on Linux, but this would be a bitch to get right
>> on Windows.
>>
>
> What I would like to see (and experimented with once) is for Lua to load the
> Lua module and call the luaopen_ function by passing in a structure of
> pointers to all the exported Lua functions.
>
> struct lua_Exports
> {
> ...
> void (*lua_pushvalue) (lua_State *L, int idx);
> };
>
> int luaopen_mymodule(lua_State *L, lua_Exports *exports);
>
> A helper function called by luaopen_mymodule could be made available to
> expand that structure into global variables:
>
> /* lua_exportglobals.h */
> void (*lua_pushvalue)(lua_State *L, int idx);
>
> void lua_copyexportstoglobals(lua_Exports *exports)
> {
> lua_pushvalue = exports->lua_pushvalue;
> }
>
> Then all other Lua use is the same.
>
> There are important benefits to this approach. The Lua module would never
> need to link against the Lua DLL. An embedded static Lua distribution in an
> executable could load any Lua module as easily as lua5.1.dll; this can't
> happen right now as the Lua module .dll/.so embeds the Lua DLL name. Worse,
> on Mac OS X, the full path to the Lua shared library is embedded in the
> module. The shared library MUST be at that location. To run a Lua
> distribution local to my application, I have to recompile everything and use
> @executable_path (which isn't always convenient).
>
> Thoughts?
I think TCL is now using a similar approach.
Another solution, would be to use a custom DLL loader for Lua modules,
and whenever a symbol is imported from lua51 module, it would instead
of loading it look for that symbol in all currently loaded modules of
the process.
Actually, I wonder if the stock Windows DLL loader doesn't already
have, I don't know, a special module name or something similar that
could be used in the import section to trigger such a mechanism. This
would allow to build unix-like shared libraries.