I have a few questions about this announcement.
1st question:
Lua scripts have their place under <texmf>/scripts/lua already,
I thought the lua scripts in the cont-tmf.zip distribution are
residing in <texmf>/scripts/context/lua/. Is this a change or are they
different files?
2nd question:
In many instances the system location to place lua libraries is
somewhere like
/usr/local/lib/lua/5.1/lpeg.so etc. for dynamic libraries
/usr/local/share/lua/5.1/re.lu etc. for lua coded modules
See the discussion on page 140 of the book Programming in Lua by
Roberto Ierusalimschy.
Will these locations be put on the searchpath too?
Or will the environment variables LUA_PATH and LUA_CPATH, mentioned in
the above, be included in the search?
Finally a wish related to the build/make process, since that also
seems to undergo a change. At present each compilation run also
compiles ctangle. Often that program is already in the TeX
distribution. Is it possible to use that instead and resort to
compilation only when it cannot be found?
Hans van der Meer
On 4 jan 2009, at 15:10, Taco Hoekwater wrote:
Hi,
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
kpse.find_file().
The immediate candidates for inclusion are:
from lpeg, currently not distributed at all
luatex/lua/re.lua
from luasocket, currently compiled into the executable:
luatex/lua/socket.lua
luatex/lua/ltn12.lua
luatex/lua/mime.lua
luatex/lua/socket/http.lua
luatex/lua/socket/url.lua
luatex/lua/socket/tp.lua
luatex/lua/socket/ftp.lua
luatex/lua/socket/smtp.lua
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?
Best wishes,
Taco
_______________________________________________
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
_______________________________________________
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
