I am doing something similar with lubyk:
1. foo.lua loads "foo/vendor"
2. the compiled modules go in foo/vendor.so
3. that's it.
Note the your open function in "vendor.so" 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
http://github.com/lubyk/lubyk. Have a look at a typical module with vendor code like modules/zmq.
GaspardOn Thu, Feb 10, 2011 at 10:55 PM, Peter Odding
<peter@peterodding.com> 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.so" ("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
[1] http://peterodding.com/code/lua/apr/
[2] http://github.com/xolox/lua-apr/blob/master/src/apr.lua
[3] http://github.com/xolox/lua-apr/blob/master/src/lua_apr.c
