tech-userlevel archive

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

Re: Lua modules, paths, man pages etc.

Am 07.10.11 10:46, schrieb Iain Hibbert:
> On Fri, 7 Oct 2011, Adam Hamsik wrote:
>>> Since this will be the first Lua module in our tree, it will set the
>>> standard for further modules, so I think we should briefly think about
>>> what to put where.
>>> We need a place for the source code.
>>> Is src/lib/lua<whatever>/ rasonable?  (Lua modules that are written in
>>> C are shared objects.).  Or should it be src/lua/<whatever>/?  I tend
>>> to prefer the latter.
>> Because destination dir is /usr/lib I would prefer to see lua modules in
>> src/lib. To have them better organized I would like to have them in
>> their own subdir src/lib/lua/<whatever>.
> Actually, I have been thinking that it would be best to place the Lua
> sources in the place where they are relevant just like we do for C
> sources. This means that for instance a Lua module that interfaces with
> libbluetooth (I have made some of that) should be in src/lib/libbluetooth,
> and the Makefile just includes <> and defines the appropriate
> variables.
> This means dependencies will be simpler to handle too, since it is
> unlikely that an interface module will need to depend on libraries that
> the library it interfaces to does not.

I don't really like that.  I prefer them in src/lib/lua, since there
will be modules that don't have a place where they are relevant.  Not
every module is necessarily a binding or interface to sth, some may be
freestanding, e.g. a json encoder/decoder that I have ready.

> For a scriptable program that might want to provide a module then it works
> similarly, just add <> and name the modules
>>> We need  Ideas about that one?
> I have one that works well (have built several architectures without
> incident), except that does not coexist well since it dirties
> its environment by redefining some suffix rules. I have not looked at it
> deeply, but I thought perhaps it would be better to move the .pico, .po
> etc rules into so that eg can use the correct flags
> without needing to duplicate the logic behind them

Looking forward to that one.

> what I did in the meantime for libbluetooth is, added the module sources
> as eg lib/libbluetooth/Lbluetooth.c, and pushed the build into SUBDIRs to
> keep them separate for now
> eg
> src/lib/libbluetooth/Makefile
>   SUBDIR+= library .WAIT modules
> src/lib/libbluetooth/library/Makefile
>   (the original Makefile, with .PATH ${.CURDIR}/..)
> src/lib/libbluetooth/modules/Makefile
>   (the Lua module Makefile, with .PATH ${.CURDIR}/..)
> iain

Home | Main Index | Thread Index | Old Index