Re: Lua modules, paths, man pages etc.

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

Am 08.10.11 02:19, schrieb James K. Lowden:
> On Fri, 07 Oct 2011 09:46:01 +0200
> Marc Balmer <marc%msys.ch@localhost> wrote:
> 
>> 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.
> 
> What is the technical advantage to segregating by source
> language?  It seems to me src should be organized by function, not
> source language.  If ls(1) gets rewritten in lua, why wouldn't the code
> be in src/bin/ls?  

It is *not* segregated by source language, but by funciton.  The Lua
modules I am referring to here are written in C.  They provide
functionality, usually bindings to some C functions, to Lua scripts.

> 
> My system has 5 executables in /sbin that aren't in C; they're shell
> scripts.  There's no /sbin/bourne directory.  If /sbin/nologin gets
> rewritten in C, it stays there.  
> 
> The same goes for libraries.  I know in e.g. /usr/pkg/lib we have lua/,
> tcl/, perl5/, et alia.  But why?  We don't have c++/.  
> 
> Organize by function.  That way, someone searching for the source code
> or library doesn't have to know what language it's written in.  And if
> the implementation changes, the location doesn't.  

It is organized by function.  The 'lua' in the paths refers to the fact
that they are used by Lua, but does not indicate that they are written
in Lua.