Re: A place for Lua module sources

[Marc Balmer <mbalmer%NetBSD.org@localhost>]

Iain,

>> 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
> together..
> 
> I started constructing a generic <bsd.lua.mk> file that takes eg
> 
>   LUA_MODULES=bluetooth sdp sdp.attr sdp.data sdp.uuid sdp.profile
> 
>   LUA_SRC.bluetooth=    lua_bluetooth.c
>   LUA_SRC.sdp.data=     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 <bsd.lua.mk>
> 
> and so far builds/installs
> 
>   /usr/lib/lua/5.1/bluetooth.so
>   /usr/lib/lua/5.1/sdp.lua
>   /usr/lib/lua/5.1/sdp/attr.so
>   /usr/lib/lua/5.1/sdp/data.so
>   /usr/lib/lua/5.1/sdp/uuid.lua
>   /usr/lib/lua/5.1/sdp/profile.lua
> 
> 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 <bsd.lib.mk> and
> <bsd.prog.mk> with source files in the same directory but I'm not sure
> thats completely possible (bsd.lib.mk provides some modifications to the
> .c.o rules for example)

That sounds interesting.  Btw, the filename extension of compiled Lua
files does not really matter, even the filename extension of Lua sources
does not matter.  Lua will happily execute e.g.
/etc/myshinynewproggy.conf ...

Maybe you could committ your Makefile stubs, so we can work on them (and
use them...)

> 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.

Ack.

> 
> 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
> first)

Thats sounds almost fine, though I'd rather leave out the dash, i.e.
src/external/mit/luaposix etc.  This should be documented somewehere, imo.


> do you have any make logic already implemented for modules?

Not really.  I have abused the Makefiles to compile Lua source code in a
rather suspect way, though...