[Dev-luatex] <texmf>/luatex is coming
Hans van der Meer
H.vanderMeer at uva.nl
Sun Jan 4 17:05:48 CET 2009
I have a few questions about this announcement.
> 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
In many instances the system location to place lua libraries is
/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
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:
> 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
> 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,
> dev-luatex mailing list
> dev-luatex at ntg.nl
More information about the dev-luatex