Re: [NTG-context] new release (Modified by Gerben Wierda)
On May 10, 2006, at 19:13, Hans Hagen wrote:
Thomas A. Schmitz wrote:
Hans,
do I need to re-report that format generation with texmfstart newtexexec --make is still broken on OS X (I'll check on my linux box later)? I still get these monstrous paths like
TeXExec | tex engine path: .:/Users/tas/texmf/web2c//:!!/usr/local/ teTeX/share//share/texmf-local/web2c//:!!/usr/local/teTeX/share// share/texmf/web2c//:!!/usr/local/teTeX/share//share/texmf-dist/web2c// pdfetex
btw, i cannot test the mac here since the machine is broken (does not start up and i already wasted half a day on it)
It seems like not the real paths are taken but only the main path and texmf-local, texmf-dist and such are hard coded subdirectories. This is one reason why I do not use the standard directories (like texmf-local and texmf-dist, but texmf.local, texmf.gwtex, texmf.tetex), to catch path `hard coding' errors as soon as possible. Another possibility (also a type of hard coding error) is parsing the wrong texmf.cnf file yourself instead of asking for the right paths by using kpsewhich. G
Gerben Wierda wrote:
On May 10, 2006, at 19:13, Hans Hagen wrote:
Thomas A. Schmitz wrote:
Hans,
do I need to re-report that format generation with texmfstart newtexexec --make is still broken on OS X (I'll check on my linux box later)? I still get these monstrous paths like
TeXExec | tex engine path: .:/Users/tas/texmf/web2c//:!!/usr/local/ teTeX/share//share/texmf-local/web2c//:!!/usr/local/teTeX/share// share/texmf/web2c//:!!/usr/local/teTeX/share//share/texmf-dist/web2c// pdfetex
btw, i cannot test the mac here since the machine is broken (does not start up and i already wasted half a day on it)
It seems like not the real paths are taken but only the main path and texmf-local, texmf-dist and such are hard coded subdirectories. This is one reason why I do not use the standard directories (like texmf-local and texmf-dist, but texmf.local, texmf.gwtex, texmf.tetex), to catch path `hard coding' errors as soon as possible. Another possibility (also a type of hard coding error) is parsing the wrong texmf.cnf file yourself instead of asking for the right paths by using kpsewhich.
indeed texexec is configured to bypass kpse (i played with the kpse library and the interface is too unstable; also, depending on the situation, a ruby version is faster and more suitable for serving multiple trees esp when i enable the run-as-service option) one can test with: set KPSEFAST=no (maybe i should only make that one available when one installs a minimal-conforming tree) i'll add the gw specific paths to the cnf location method (esp the way kpse locates its cnf files is not really well defined and standardised since kpse itself uses this autoparent stuff); btw, doesn't gwtex set the TEXMFCNF env variable? 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 -----------------------------------------------------------------
btw, doesn't gwtex set the TEXMFCNF env variable?
It does not get a useful value. TEXMFCNF is defined at compile-time and its setting in a texmf.cnf file is ignored for obvious reasons. The compiled-in version shows my compile environment which differs from the install environment on people's system. Try kpsewhich -expand-var=\$TEXMFCNF in a Terminal window. I had to do this if I wanted to make my TeX install relocatable and I had to make it relocatable to enable the option that people who do not have sysadmin privileges can install the TeX i-Package in their home directory and still work with it. In short: everything in TeX is relocatable at run time except the location of texmf.cnf. G
Gerben Wierda wrote:
btw, doesn't gwtex set the TEXMFCNF env variable?
It does not get a useful value.
TEXMFCNF is defined at compile-time and its setting in a texmf.cnf file is ignored for obvious reasons. The compiled-in version shows my compile environment which differs from the install environment on people's system.
Try kpsewhich -expand-var=\$TEXMFCNF in a Terminal window.
I had to do this if I wanted to make my TeX install relocatable and I had to make it relocatable to enable the option that people who do not have sysadmin privileges can install the TeX i-Package in their home directory and still work with it.
In short: everything in TeX is relocatable at run time except the location of texmf.cnf.
but how then does it locate texmf.cnf, relative to the bin path of kpsewhich? 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 -----------------------------------------------------------------
On May 11, 2006, at 17:16, Hans Hagen wrote:
Gerben Wierda wrote:
btw, doesn't gwtex set the TEXMFCNF env variable?
It does not get a useful value.
TEXMFCNF is defined at compile-time and its setting in a texmf.cnf file is ignored for obvious reasons. The compiled-in version shows my compile environment which differs from the install environment on people's system.
Try kpsewhich -expand-var=\$TEXMFCNF in a Terminal window.
I had to do this if I wanted to make my TeX install relocatable and I had to make it relocatable to enable the option that people who do not have sysadmin privileges can install the TeX i-Package in their home directory and still work with it.
In short: everything in TeX is relocatable at run time except the location of texmf.cnf.
but how then does it locate texmf.cnf, relative to the bin path of kpsewhich?
The first texmnf.cnf it tries is indeed located that way: ../../texmf.cnf This is the only reason my precompiled TeX distro is relocatable. G
participants (2)
-
Gerben Wierda -
Hans Hagen