[dev-context] integrating context mkiv, luatex, and fmtutil, mktexlsr, etc

Norbert Preining preining at logic.at
Wed Oct 3 13:06:34 CEST 2007

Hi Hans, hi all,

On Mi, 03 Okt 2007, Hans Hagen wrote:
> Norbert Preining wrote:
> >	$ENGINE -ini  -jobname=cont-en -progname=context -8bit *cont-en.ini
> that won't work because luatex by itself cannot take care of the stubs 
> it may need for starting up (how could it know -)
> making a format (at least formkiv, but also for plain if you want) 
> boils down to:
> - making a lua stub file (lua)
> - compiling that for fast loading (luc)
> - making a format

Ok, that said we have to adjust the fmtutil script. Currently the
information stored in the fmtutil.cnf file is
	$format $engine $sometestfile $restofcmdlineoptions
These lines normally trigger a call to 
	$engine -ini -jobname=$format -progname=context $cmdline
(the progname is already a special case AFAIR).

Now for combinations of
	cont-?? $engine ...
we could switch to calling
	texexec --engine $engine --make ??
Is this right? 

But this doesn't work with luatex:
	texexec --engine luatex --make en
still runs luatex. (Strange btw, isn't it?)

So, what is the *recommended* way to generate context formats for the
following engines:
	pdftex:		ini, texexec
	xetex:		ini, texexec
	aleph:		ini, texexec
	luatex:		???
(ini: calling $engine -ini ..., 
texexec: calling texexec --engine $engine --make ??)

> $ENGINE --luaonly luatools.lua --make --compile cont-en
> $ENGINE --luaonly luatools.lua --make --compile plain

Ok, so one could call

	luatools --make --compile cont-en


For all those texexec/luatools creating of formats there is another
problem: The formats are placed in quite arbitrary locations. TEXMFVAR
should be the right place, but this is not honoured (in my case texexec
did put it into TEXMFHOME!). Or at least it should be *fixed* to which
tree the format will be written.

Then there is the problem that luatools --make does not work without any
cache, well, see below.

> >- integration into mktexlsr
> >  see my other email about multiple cache merging, but to some up:
> >  . cache should be read from more then one directory, eg from
> >    TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff)
> >  . single cache updates should be possible:
> >	luatools --generate $HOME/texmf
> i'll see what i can do
> >    should generate the cache for $HOME/texmf in $TEXMFCACHE
> what exactly do you mean with integration? calling luatools?

Well, the idea is that if someone calls
	mktexlsr $tree
and luatex/context is installed, the luatex cache is also updated. The
idea is that we just plug in some code that is only executed if context
and luatex is installed, that updates the cache.

Take for example Debian: One can install texlive packages, plus
independent context and luatex packages. But all the add-on packages for
fonts etc only call mktexlsr. We will have a hard time forcing them to
add some magic that in case of the presence of luatex/context also the
cache (for system files) is updated.

My idea is to have something mktexlsr.d/ directory where packages can
drop scripts (same would work also in TeX Live) and mktexlsr at the end
of the run calls these scripts. So if luatex drops something, and
context drops something, we could organize that not only the mktexlsr
db, but also the luatex cache is up2date.

> >Other things I realized as user:
> >- running texexec --lua test.tex generates the format in 
> >	~/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats
> >  but it creates it again and again. 
> strange, since texexec --lua is not supposed to generate a format at all

Maybe I missed something ...

> >- If I move the generated files from the above dir to
> >	~/.texmf-var/web2c/luatex/
> >  and regenerate the luatex-cache with --generate --verbose the next run 
> >  does not work:
> (i wonder what i do with the . in .texmf-var -)

Aehmmm, but the luatex cache will quite sure be set to something with a
dot, at least the local one ;-)


I think it is time to discuss all this problems now, otherwise inclusion
into TeX Live upstream and Debian will make problems. Ok, I can just
ship the stuff and don't produce and cache/formats whatsoever for MkIV,
MkII still works quite well. But I guess it would be nice to sort this
out in a good way for all parties.

Best wishes


Dr. Norbert Preining <preining at logic.at>        Vienna University of Technology
Debian Developer <preining at debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
A rucked-up edge of carpet or linoleum which everyone says someone
will trip over and break a leg unless it gets fixed. After a year or
two someone trips over it and breaks a leg.
			--- Douglas Adams, The Meaning of Liff

More information about the dev-context mailing list