[tex-live] mysterious mpost problem
Hans Hagen
pragma at wxs.nl
Wed Jan 19 18:21:31 CET 2005
Olaf Weber wrote:
> Basically, the problem seems related to the way the code infers a
> progname if the '-mem=foo' argument is given, and doesn't if '&foo' is
> used.
that's a subtle differnece indeed
> - A partial solution is to always require the -progname for tex, mf,
> mpost if a different progname than the name of the program is
> desired. This is easy to implement, though it may break backward
> compatibility... (Not that we're strangers to that; and I hope it
> would complete the cleanup of that part of the options interface.)
dangerous to break that compatibility
> - For mpost in particular, it also appears that some values cannot be
> safely used from the texmf.cnf for an existing mem, and therefore
> should just be stored in the mem at dump time and used from there.
> This is easy enough for me to do, if someone can tell me which ones.
>
> Storing the progname at dump in the mem file is not a solution for
> this particular problem.
>
> Explcitly specifying the progname option is safest. The rule-of-thumb
> is that -progname should be -mem name, and since -mem name is adopted
> during runs not not during -ini, -progname needs to be explicit at
> -ini.
on the other hand, now one can share mem settings *which is what happens with
context: many formats, one progname)
how about defaulting to the program name (binary) if -progname is missing?
[there are a few more such strange inconsistencies:
pdfetex + pdfetex.pool
mpost + mp.pool (i'd expect mpost.pool)
the same for names of dump formats. maybe all these things should default to the
binary's name]
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
More information about the tex-live
mailing list