C module and a Lua stub with the same name

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

C module and a Lua stub with the same name

Ivan Kolev-2
Hi,

I recently discovered that Lua 5.1 was finally officially released. Congratulations. The list of changes is impressive and worth the waiting.

I returned to Lua (my job in the last few years didn't have any touching points with Lua, which I regretted) when I decided to code an automation tool for Windows, similar to the popular AutoIt ( http://www.autoitscript.com/ ). There exist a few such tools written in Python and Perl, but for me it was a better solution to write my own in Lua for several reasons (for the same reasons I decided not to use AutoIt).

So, after studying the new module system I couldn't find how to easily make a C module and Lua stub with the same name. E.g., I have a MyModule.dll and MyModule.lua. Naturally, MyModule.lua is the first found by require "MyModule" somewhere on the LUA_PATH. Then MyModule.lua needs to load MyModule.dll from its own directory, but this cannot be done so easily. I cannot use require which would search the LUA_CPATH, and if I decide to use package.loadlib, I'd need to enumerate the package.path or cpath myself to find the directory where MyModule.lua is. And it may happen that my search finds *another* copy of MyModule.dll instead of the one placed next to the currently loaded MyModule.lua...
Is there a simple solution to this problem? Currently I simply name the .dll and the Lua stub differently (e.g. MyModule.lua and MyModuleDLL.dll) (which suffers from the same incorrect-copy-from-another-directory problem).
I guess if require passed as an argument to the Lua module the directory where it was found, then the Lua stub could easily load the .dll from the same directory.

BTW, the manual uses a bit terse style, which is understandable, but sometimes the matters are a bit complex for a short description, and the module system is one of them. A few examples of typical usages would be welcome. I guess the second edition of Roberto's book has such examples, and I may get it eventually (though I already have the first edition).

Best Regards,
Ivan

Reply | Threaded
Open this post in threaded view
|

Re: C module and a Lua stub with the same name

D Burgess-4
> I guess if require passed as an argument to the Lua module the directory where it was found, then the Lua stub could easily load the .dll from the same directory.

Well you are in luck.

Try,

table.foreach(debug.getregistry(),print)

you will see stuff like

LOADLIB: .\mypackage.dll userdata: 0032BC88

This is the path where the package was found.

> Is there a simple solution to this problem?
Add you own loader to package.loaders or change the order
of the loaders.


Re: the Blue PIL, the description for require is pretty good.

David B.

On 4/12/06, Ivan Kolev <[hidden email]> wrote:

> Hi,
>
> I recently discovered that Lua 5.1 was finally officially released. Congratulations. The list of changes is impressive and worth the waiting.
>
> I returned to Lua (my job in the last few years didn't have any touching points with Lua, which I regretted) when I decided to code an automation tool for Windows, similar to the popular AutoIt ( http://www.autoitscript.com/ ). There exist a few such tools written in Python and Perl, but for me it was a better solution to write my own in Lua for several reasons (for the same reasons I decided not to use AutoIt).
>
> So, after studying the new module system I couldn't find how to easily make a C module and Lua stub with the same name. E.g., I have a MyModule.dll and MyModule.lua. Naturally, MyModule.lua is the first found by require "MyModule" somewhere on the LUA_PATH. Then MyModule.lua needs to load MyModule.dll from its own directory, but this cannot be done so easily. I cannot use require which would search the LUA_CPATH, and if I decide to use package.loadlib, I'd need to enumerate the package.path or cpath myself to find the directory where MyModule.lua is. And it may happen that my search finds *another* copy of MyModule.dll instead of the one placed next to the currently loaded MyModule.lua...
> Is there a simple solution to this problem? Currently I simply name the .dll and the Lua stub differently (e.g. MyModule.lua and MyModuleDLL.dll) (which suffers from the same incorrect-copy-from-another-directory problem).
> I guess if require passed as an argument to the Lua module the directory where it was found, then the Lua stub could easily load the .dll from the same directory.
>
> BTW, the manual uses a bit terse style, which is understandable, but sometimes the matters are a bit complex for a short description, and the module system is one of them. A few examples of typical usages would be welcome. I guess the second edition of Roberto's book has such examples, and I may get it eventually (though I already have the first edition).
>
> Best Regards,
> Ivan
>
>
Reply | Threaded
Open this post in threaded view
|

Re: C module and a Lua stub with the same name

Ivan Kolev-2
D Burgess wrote:

>> I guess if require passed as an argument to the Lua module the directory where it was found, then the Lua stub could easily load the .dll from the same directory.
>
> Well you are in luck.
>
> Try,
>
> table.foreach(debug.getregistry(),print)
>
> you will see stuff like
>
> LOADLIB: .\mypackage.dll userdata: 0032BC88
>
> This is the path where the package was found.

But this is done only when loading C modules. And I can't have the C module load the Lua implementation, because the default loading order is Lua->C - if I had MyLib.lua and MyLib.dll in the same directory, MyLib.lua would be loaded first :(

>> Is there a simple solution to this problem?
> Add you own loader to package.loaders or change the order
> of the loaders.

If I write a library intended for common use, I wouldn't want to mess with the default loading order.

It's a pity that I had to examine Lua's source to see that the filename of the loaded Lua module is stored as debug info of the module function... somehow I didn't think about debug.getinfo
This is what I do now in the beginning of MyLib.lua:

local function loadCmodule( modname, clibext, openFunc )
        local path = debug.getinfo( 2, "S" ).source
        modname = modname or string.gmatch( path,"([^\\/]+)\.lua$")()
        assert( modname, "Could not extract module name from path" )
        path = string.sub( path, 2, - #(modname .. ".lua") - 1 )
        clibext = clibext or ".dll"
        openFunc = openFunc or "luaopen_" .. modname
        modname = modname .. clibext
        local mod = package.loadlib( path .. modname, openFunc )
        mod = mod or package.loadlib( path .. "Release\\" .. modname, openFunc )
        mod = mod or package.loadlib( path .. "Debug\\" .. modname, openFunc )
        return assert( mod, "C module " .. modname .. " not found" )()
end

local cmod = loadCmodule()

... add Lua interface here

The above function loadCmodule() (or some improved version of it) seems like a good candidate for a common utils library.

I'd be interested to see how other libraries which have a Lua stub on top of a C module deal with this issue.

Regards,
Ivan