2009-01-04 14:10:09 UTC
In one of the next releases I want to start distributing some
lua files under <texmf>/luatex/lua/
The intentions is that lua modules that are part of the luatex
lua distribution will go there, nothing else. These are files
that can be reached via the Lua require() function using the
default compile-time package.path. Lua scripts have their place
under <texmf>/scripts/lua already, and macro package specific
lua files should remain below <texmf>/tex/, to be found via
The immediate candidates for inclusion are:
from lpeg, currently not distributed at all
from luasocket, currently compiled into the executable:
Some others may soon arise form the luatex core itself, for example
for the mapping of node (sub)type numbers to strings. These ids are
static for any particular version of the executable, but they are
never actually used inside the engine, so it makes sense to split
them off into a lua module that can be loaded on demand.
One warning and one question.
First the warning, for Hans in particular: make sure you start using
require() for all of the external lua modules that are embedded in
luatex. As soon as this new subsystem is in place, you can no longer
use functions like socket.bind() without require-ing the module first!
Second the question, and that is mostly for Martin: when luatex starts
shipping more stuff than just a single executable, it begins to make
sense to have an installation method. It could be nice to be able
$ ./configure; make; make install
at toplevel, instead of
$ ./build.sh ; cp <bunch of whatever to wherever> ; ...
To be able to that, the current build scripts have to be rewritten
into a unified Makefile.in. The new, to-be-created configure script can
be rather stupid and may not even have to be autoconf-generated.
The aim is to get a predictable user interface, not automating the
whole big build process. For example, if "make clean" would delete the
build tree (if there was one), then the "--make" commandline switch
would no longer be needed. Targets like "make cross" and "make native"
could replace ./build.sh.linux and ./build.sh.cross, etc.
Would you (or anyone else) be willing to work on that?