New package: Lua

[Ag. Hatzimanikas]

About Lua.

Lua was designed as an extension language and because of this is small. However, this doesn't mean is not rich or it's not expressive (quite the opposite, especially if you know that Scheme was a source for a major inspiration (1) for Roberto Ierusalimschy (the main Lua author).

The Lua project is hosted at ​http://www.lua.org

Current version is 5.1.4 and it has no dependencies.

The Lua distribution doesn't provide a configure script but just a Makefile, so there are just "make" targets. To compile Lua we just need to issue, a "make linux" from the top level off the distribution.

By default the installation goes into the /usr/local hierarchy, so we need to use the INSTALL_TOP and INSTALL_LIB variables to change that, with:

make install INSTALL_TOP=/usr INSTALL_LIB=/usr/lib

Lua ships with an etc/lua.pc file, that also needs some fixing:

%s@/local@@

As a final step we place the .pc file into /usr/lib/pkgconfig with 0644 permissions.

That's it. Using those instructions the package provides (analytically):

/usr/bin/lua
/usr/bin/luac
/usr/include/lua.hpp
/usr/lib/liblua.a
/usr/lib/pkgconfig/lua.pc
/usr/man/man1/lua.1
/usr/man/man1/luac.1
/usr/include/lauxlib.h
/usr/include/lua.h
/usr/include/luaconf.h
/usr/include/lualib.h

(not so much as expected)

Now. As it has been said already, Lua is tiny and minimalist so doesn't provides any batteries with it, like the most scripting languages usually do today and developers are used to have.

To overcome this, the Lua community had created many excellent modules (to complement the Lua core), which they provide specifics functions; like a socket interface (2), or luaposix(3) or modules that offering various bindings, e.g., gui toolkits.

All these modules (usually are hosted at luaforge.net) are not officially supported.

A package system was implemented, which is the LuaRocks (4). The purpose of LuaRocks is to (per word) provide a deployment and management system for Lua modules, something like cpan or RubyGems. The current release is in the first stable version, with minor releases that offers mainly bug-fixes but with no visible changes in the functionality. The LuaRocks team is on a process to a 2.* new stable release, with a big difference from current stable.

Currently LuaRocks is installed into /usr/share/lua/5.1/luarocks and by default all the installed modules goes into /usr/lib/luarocks/rocks hierarchy. The user then should include a require("luarocks")" on top of the script to start using the modules.

That is what is going to change. Modules would be installed to the standard locations, i.e., LUA_PATH and LUA_CPATH.

Now. The above variables are both paths, that Lua is searching for modules.

LUA_PATH for the 5.1.4 release is /usr/share/lua/5.1 and LUA_CPATH is /usr/lib/lua/5.1 (assuming prefix is /usr).

The simple difference between those two, is that in LUA_PATH are located modules which are just plain text files with a .lua extension, and in LUA_CPATH are located modules written in C with embedded Lua code (*.so files).

Those two variables can be used in runtime, so the user should know about their importance.

There is another approach.

Below are vim substitutions to "src/luaconf.h" which we can apply them before the installation, as the very first step (if I remember well, I've adopted them from a gentoo patch), where we are defining where Lua will search for modules, that means in our case under /usr/{lib,share}/lua/5.1.

%s@^#d.\{-}e \(LUA_ROOT\).*@&\r#define \12\t"/usr/"@
%s@^\(#d.*\)\(LUA_LDIR\)\(.*T\)\(.*\)@&\r\1\22\32\4@
%s@^\(#d.*\)\(LUA_CDIR\)\(.*T\)\(.*\)@&\r\1\22\32\4@
%s@^\s*".\{-}\s\(LUA_LDIR\)\(.\{-}\s\)\1\(.*\)\n\(\s*\)@&\12\2\12\3\r\4@
g/\.so;/s/\(.*\)"/\1;" LUA_CDIR2"?.so"/

So in a conclusion, we have to write an additional page or extend the lua page (that might add some bloat, though this depends from the implementation) describing the above and with instructions to:

• install and use LuaRocks

• download and install some important and popular Lua modules (I do have the instructions and I can provide them when needed)

Another thing to know is: Do we want to build the shared library, liblua.so or just the static liblua.a? If we need to build the shared library, we should do a research to see how the other distributions do build the (shared) library. There is also a patch written for 5.1.1, which can still be valid, from Luca Piol at: ​http://wiki.linuxfromscratch.org/blfs/attachment/ticket/2173/lua-5.1.1-makeso-1.patch

As I am not in a position to build a 6.5 LFS, I can't really do this ticket, so I would welcome a collaboration from editor(s) that are interested.

1. ​http://www.computerworld.com.au/article/260022/-z_programming_languages_lua

2. ​http://luaforge.net/projects/luasocket/

3. ​http://luaforge.net/projects/luaposix/

4. ​http://www.luarocks.org/

[Guy Dalziel]

I'll add this when ELinks 0.12 is released, that way I can do them both together.

[Ag. Hatzimanikas]

Fixed some typos to the description. Also see ticket #2929 for a new Lua Modules page.

[Randy McMurchy]

I know the old ticket was marked future, and this new one is marked for 6.5.

I cannot tell the Editors which tickets to work on, but I can *suggest* that we concentrate more on existing packages and getting them up to date than we do adding new ones. But I'm in no position to say much, as I haven't done any package updates in quite some time.

Again, if an Editor wants to take on a new package, and would rather do that than update existing ones, drive on brother. But it does slow down the process of getting a new release out.

[rt]

Keep as external dependency.

[bdubbs@…]

Milestone renamed