tech-userlevel archive

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

Re: A place for Lua module sources

On Sun, 16 Jan 2011, Marc Balmer wrote:

> All of Lua currently resides in external/mit/lua.  For now that is the
> library and the lua/luac binaries.
> We should also define a location in the source hierarchy where we can
> place source code for modules.  Since all modules I stumbled over so far
> are under the same MIT license as Lua itself, I suggest to place them
> under the external/mit/lua directory as well.  Maybe under
> external/mit/lua/modules/<name_of_module>/.
> My idea is to import a small set of modules that interface functionality
> in base:
> - posix: General POSIX functions
> - ldap: Interfacing LDAP
> - gpio: GPIO access
> - netbsd: Very specific NetBSD functionality not found in posix or any
> other module (e.g. accessing sysctls)
> Opinions on the path for modules?  Or on the modules themselves?

Ah, good.. I have been stumbling along these lines this week, was toying
with some Lua bindings for bluetooth(3) and sdp_data(3) library functions
because I thought it would be interesting to make sdpquery take the name
of a Lua script as a command then provide a set of scripts to match
current functionality (search, record & browse). I haven't got that far
yet, but this means that I would have modules to install for
lib/libbluetooth and usr.bin/sdpquery and was wondering how to bring it

I started constructing a generic <> file that takes eg

  LUA_MODULES=bluetooth sdp sdp.attr sdp.uuid sdp.profile

  LUA_SRC.bluetooth=    lua_bluetooth.c     lua_sdp_data.c

  # (implied, not necessary)
  #LUA_SRC.sdp=         sdp.lua
  #LUA_SRC.sdp.attr=    sdp_attr.lua
  #LUA_SRC.sdp.uuid=    sdp_uuid.lua
  #LUA_SRC.sdp.profile= sdp_profile.lua

  .include <>

and so far builds/installs


or it can generate .luac if HAVE_LUAC is defined though currently our lua
does not load .luac modules by default and I guess that would require that
luac be added to tools. Also, .luac files are MD and can be somewhat
dependent on the "luac" compiler options so I'm not sure its useful to
worry about them at this time..

My intention was that this could be used alongside <> and
<> with source files in the same directory but I'm not sure
thats completely possible ( provides some modifications to the
.c.o rules for example)

Anyway, after all that back to your question..  I think external Lua
modules should just follow the existing scheme as laid out in
external/README, eg we should just put them in their own directories as
they are not the same package as Lua and putting them under "lua/modules/"
directly brings further questions about "lua/dist/" and it might get
confusing if a different licence is needed.

For the Lua POSIX module then, we would use src/external/mit/lua-posix/
with dist/ and lib/ subdirs as normal, and a native Lua Bluetooth module
would be in src/lib/lua-bluetooth so it can be scheduled after
dependencies (it cannot go under libbluetooth/ since SUBDIR is processed

do you have any make logic already implemented for modules?


Home | Main Index | Thread Index | Old Index