Frank � wrote:
> Hans Hagen <[EMAIL PROTECTED]> wrote:
>
>
>> Sanjoy Mahajan wrote:
>>
>>> A system-wide installation, if done cleanly, would be much easier
>>> (as plink pointed out). If you (or 'texexec --make' to generate the
>>> formats) ask kpathsea where to put the format files, it'll give you
>>> a directory in TEXMFHOME, so a per user install. But how do you ask
>>> kpathsea the correct question so that it'll tell you where they
>>> should go for a system-wide install?
>>>
>>>
>> you can't and i remember asking for such a feature but ... ;
>>
>
> Can you point me to this discussion? I think it doesn't need more as
> what fmtutil-sys, updmap-sys and texconfig-sys do before calling
> fmtutil, updmap or texconfig, respectively:
>
> v=`kpsewhich -var-value TEXMFSYSVAR`
> c=`kpsewhich -var-value TEXMFSYSCONFIG`
>
> TEXMFVAR="$v"
> TEXMFCONFIG="$c"
> export TEXMFVAR TEXMFCONFIG
>
> exec updmap ${1+"$@"}
>
> However, it would be probably more elegant and context-like to not have
> texexec and texexec-sys, but rather a commandline switch - in this case
> the handling would have to be done in the perl (or ruby?) scripts, which
> is somewhat trickier.
>
concerning fmtutil: there was a time that texexec could call fmtutil,
but the lack of engine support (as taco explained, it was a trade off
for simplifying the fmt suffix but part of the bargain was nog kept) as
well as all kind of messy 'aliasing' going on in tex distributions
(leading to dropped patterns and fonts) made us decide to drop that;
another reason is that distrubutions like texlive more or less assume
a'wipe your system clean and install new' policy which is not possible
if you have aditional trees, run older binaries with newer trees, etc,
which is why texmfstart came around: relocating script paths and enc/map
paths was done in not downward compaible ways (which in turn is the
reason why context ships with all kind of tools to clean up and
reorganize trees etc).
i have no problem with adding a commandline switch which tells texexec
where to put the formats although, since your scripts already set
variables, the most natural way would be to adapt
TEXFORMATS=someplace/web2c/{$engine,}
to which texexec already listens, but if some additional switch/feature
is needed it can be done
Concerning updmap, as Taco explains in another mail, context does not
use updmap output; this has a long history:
- context had runtime map loading before updmap was around
- we never used the 'huge map files' because it was real slow (this was
fixed at some point, hash instead of linear search)
- merging map entries in to one big file is dangerous (there can be
multiple instances of fonts, same name, different metrics, same
longname, different font etc)
- we want clean and easy ways to add support for commercial fonts (which
is the majority)
- pdftex and dvipdfmx were adapted to do run time loading
so, there is no need to spend time on updmap for context.
I have no idea what texconfig does but i don't think context needs it (i
may be wrong).
>
>> the only
>> way to figure that out is to check all format paths and take the first
>> one that fits; unfortunalty the tetex paths are rather messy so it's
>> hard to predict in what permutation of home, usr, share, sys, opt *
>> local * tex, TeX, teTeX, whatever * texmf, texmflocal, texmf-local,
>> texmf-teTeX, texmf-dis, texmf.local, texmf-whocares * web2c,
>> web2c/engine etc etc a format may end up;
>>
>
> I'm not sure what you mean. The default TEXMF path for teTeX (and I
> think also for TeXlive) is
>
> TEXMF =
> {!!$TEXMFCONFIG,!!$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}
>
the problem with texmf is that there can be many variants, and there
have been in the past; here i now have:
TEXMF={!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFEXTRA,!!$TEXMFMAIN}
texmfproject : a tree for project related files, these will not be wiped
out with an update
texmffonts : a safe place for commercial fonts, also not being wiped
out (may have older tds structures)
texflocal : the place for updates and specific user settings
texmfextras : introduced a few years ago in texlive for non free stuff
(first dvd productions)
texmfmain : on my system a mere copy of the latest tex live, just the
whole lot
parallel this i have texmf-mswin, texmf-linux, texmf-.... with web2c
and bin paths
interesting is that a request for texmfproject and texmffonts on the tex
live list was rejected by tetex folks because they didn't want extra
paths, but see what extra paths tetex adds -)
concerning tex live: i must admit that i only copy the tree and use a
much simplified texmf.cnf file which as a side effect makes tex run faster
anyhow, texexec cum suis just expand the texmf var so any setup should
work but i rely on other context users to report problems;
> where the first three are per-user, the others are system trees. An
> explanation about installing does not need to know whether, for example,
> TEXMFLOCAL is called texmf.local or texmf-local or
> /usr/local/share/texmf. The only problem might be that some users
> change the order or the trees, but that's not a big problem if we
> suggest to use the default path.
>
sure, but the fact that the 'real' names change every now and then makes
it hard for users to cary a history around without renaming; also, one
of the ideas behind tds and web2c was that platforms could share trees,
which is what i like: i have one set of trees for running all platforms
(so, texmf-local it is here)
>
>> this is further complicated
>> by the fact that kpse has to do some guessing about where it's
>> configuration files are (web2c, etc, home, nowhere),
>>
>
> This is only a problem if people have more than one texmf.cnf - is this
> actually the case? I don't think I ever heard of that.
>
i dunno, but since tex distributions tend to be non-downward compatible,
i would not be surprised if users at least patch their local one
>
>> what trees make
>> sense, etc etc; and, yes, some of the paths are hard coded in the
>> binaries, so relocating is tricky ... isn't it magic that tex still
>> runs -)
>>
>
> AFAIK only the search path for texmf.cnf is hard-coded, and that can't
> be avoided. On the other hand, no one ever approached me and requested
> a relocation: What would you want, and in which cases?
>
i think that there are a few more paths in there (you sometimes see them in var
expansions, but normally they don't hurt) ; life would be easier if texmfcnf
was always taken from an env var; actually, i set all important env vars
anyway, if only because it isolates tex distrubutions (after all we're talking
about a only a few vars than determins all);
which brings me to the format again ... maybe it makes sense to set TEXFORMATS
after all but i can let texexec listen to an extra --key if needed
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
-----------------------------------------------------------------
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
