luacheia project status, July 2003

[Thatcher Ulrich <tu@...>]

Here's a status report on the luacheia project.  luacheia is a
"full-featured but modular Lua distribution."  The project website is
at http://luacheia.lua-users.org/

------------------------------
luacheia project status, July 2003

UPCOMING RELEASE
================

We are approaching an alpha release of luacheia, based on Lua 5.0,
with about a dozen modules.  Features:

* Lua 5.0 with standard interpreter, built-in libraries, and bug fixes

* built-in support for three methods of binary module loading:
  loadmodule, GluaX gluahost, and Lua's loadlib (with .dyld support on
  Darwin/OSX)

* an automated cross-platform build system using automake and libtool.
  Known to work on Win32 with MinGW/MSYS, Mac OSX, GNU/Linux,
  FreeBSD, and many Unix variants.

* modules: bit, cgi, fuzzy, luacom, md5, pcre, posix, rex, SDL, shelve,
  socket, sqlite

* simple self-testing framework

* self-installing .exe for Windows, tarball for other platforms

Look for an announcement in the next week or two.

STATUS
======

The latest project code is always available by anonymous CVS from
SourceForge.  There is a quiet but active mailing list.  There is a
slightly out-of-date website at http://luacheia.lua-users.org that
links to these resources.

We have settled most of the major architectural issues such as module
loading conventions and directory layouts.  One of the bigger
stumbling blocks so far has been the build system, based on GNU
automake & libtool.  automake & libtool have a steep learning curve
for developers, and are pretty difficult to use and debug.  There seem
to be many quirks, especially when using them to build on Win32 and
OSX.  However, they take care of a bewildering amount of
platform-specific wrangling necessary to make shared libraries on
different platforms.  And the results are pretty nice: a completely
automated ./configure script that produces generic Makefiles.

We have had lots of frustration with automake & libtool, but stick
with them due to lack of compelling alternatives.

Adapting existing Lua 5.0 libraries for use as modules has proved to
be fairly straightforward.  Adding loadmodule hooks is usually a piece
of cake.  The tricky parts usually involve setting up automatic
configuration, so that the build system can find necessary support
libraries and set platform- and system-specific #defines.

Licensing is also an area of concern.  Code that is Public Domain, or
available under the MIT License, is easily adopted.  LGPL code can be
incorporated in modules but unfortunately complicates our LICENSE.txt.
GPL'd code (such as readline!) cannot be included because it limits
binary distributions, and downstream usage of the project code,
contrary to the project goals.  Additional license variants, such as
the wxWindows license or Henry Spencer's regex license, can be
accomodated, but bloat our LICENSE.txt.  If you are thinking about
releasing a Lua add-on library, we recommend using the MIT License
(like Lua) or putting it in the Public Domain (like some of lhf's
libraries).

NEEDS
=====

Our primary needs include:

* users & testers on various platforms.  If you're adventurous and
  familiar with CVS, you can checkout the source, built it, and try
  writing some scripts.  Otherwise you should wait for the upcoming
  alpha.

* automake/libtool gurus to help resolve tricky cases and improve our
  scripts.

* module maintainers/authors.  If you're the author or user of a Lua
  add-on module, and you are comfortable with CVS, we would appreciate
  help with adding and maintaining modules.  So far, the core project
  members have been adding/maintaining various existing Lua add-ons in
  order to build some critical mass and get all the mechanisms in
  place, but if we manage to keep adding modules, this will not be
  sustainable.

* a developer interested in setting up and maintaining a better test
  framework.  There is a rudimentary test framework in place, but it
  mixes module stub-loaders with test functions, and the tests are
  extremely limited.  It would be nice to have very comprehensive
  tests, separate from the module stub-loaders.

  We would be especially interested in a wxLua guru.  We have a
  partially working wx module, which will be extremely useful when
  it's fully working.

* a volunteer to plan & organize a documentation system.  We do not
  yet have standards in place for module documentation.  We need a
  system that's easy for both module maintainers and users.

-- 
Thatcher Ulrich
http://tulrich.com