lua-users home
lua-l archive

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

I met the same problem.
I used to load both foo.lua and foo.dll by change the loaders order.
Load the foo.dll first and the foo.dll loads the foo.lua.

I think your way is better and easier.

Best Regards!

Xpol Wan

On Sat, Feb 12, 2011 at 10:19 PM, Gaspard Bucher <> wrote:
I am doing something similar with lubyk:

1. foo.lua loads "foo/vendor"
2. the compiled modules go in foo/
3. that's it.

Note the your open function in "" must be "luaopen_foo_vendor" not "luaopen_foo":

extern "C" int luaopen_foo_vendor(lua_State *L) {

For a full blown build system using CMake and handling all these cases, you can have a look at Have a look at a typical module with vendor code like modules/zmq.


On Thu, Feb 10, 2011 at 10:55 PM, Peter Odding <> wrote:
Hi Michael,

My Lua/APR binding [1] includes lots of C source code plus a few 'sugar' functions as you describe them. The easiest way I've found to combine them is more or less as you envision it:

There's a Lua script which is loaded on require 'apr', this file is named "apr.lua" [2] and is placed in one of the top level directories in Lua's module search path. The first line of this script contains:

       local apr = require 'apr.core'
       -- .. and the script ends with ..
       return apr

The binary module is called "" ("core.dll" on Windows) and is located in a subdirectory "apr" in one of the directories in Lua's binary module search path. The loader function in the binary module [3] is called "luaopen_apr_core".

The nice thing about this scheme is that your Lua script can remove some functions from the module table created in C and save those functions in local variables. Now your Lua functions can call the C functions to perform low level tasks and the C functions don't have to be foolproof because you'll be writing the code that calls them.

 - Peter Odding