Hi Hans, hi all, On Mi, 03 Okt 2007, Hans Hagen wrote:
$ENGINE -ini -jobname=cont-en -progname=context -8bit *cont-en.ini [...]
Norbert Preining wrote: 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
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining