Mail Archives: cygwin/2006/11/12/02:00:27
Why does cygwin's gnuplot setup.hint list tetex-bin in its requires: entry?
==============================
(a) gnuplot.exe has no dependency on any DLL delivered by tetex
(b) On linux, the gnuplot package does not depend on any TeX package
Fedora:
http://rpm.pbone.net/index.php3/stat/4/idpl/3411941/com/gnuplot-4.0.0-12.i386.rpm.html#requires
SUSE:
http://rpm.pbone.net/index.php3/stat/4/idpl/2815509/com/gnuplot-4.0.0-7.i586.rpm.html#requires
Mandriva:
http://rpmfind.net//linux/RPM/mandriva/2006.0/i586/media/main/gnuplot-4.0.0-7mdk.i586.html
(c) not even /usr/share/doc/Cygwin/gnuplot-4.0.0.README lists tetex as a
runtime requirement -- only a build-time requirement.
==============================
Similar issues with octave/gnuplot/tex have come up before (yeah, that
was me, too). From this thread:
octave-forge dependency?
http://www.cygwin.com/ml/cygwin/2005-12/msg00224.html
It appears that gnuplot's save command uses kpsepath and kpsexpand from
tetex-bin. While the earlier thread contains some suggestions, it was
ultimately decided that
(a) octave-forge/octave should no longer depend on tetex-bin (this
change has been made), but
(b) gnuplot should begin depending on tetex-bin simply to ensure that
kpsepath/kpsexpand are available, pending...
(c) a bug report to the gnuplot mailing list, to *check* for the
existence of a tool before exec'ing it. That bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1377786&group_id=2055&atid=102055
led to two patches (both wrong, IM-NSH-O) but it isn't clear to me which
one if either was eventually adopted (by gnuplot-4.2r1?). The two
patches do the following:
(1) on the gnuplot builder's machine, check if kpsexpand exists at
configure time. Use it during configure to determine the "correct"
paths (on the gnuplot builder's system) that will be hardcoded into the
gnuplot executable. Hope those are the correct paths on the end-user's
machine.
OR
(2) on the gnuplot builder's machine, check if kpsexpand exists at
configure time. If so, then build a gnuplot executable that will
continue to blindly call kpsexpand on the end-user's machine -- e.g. no
change. If kpsexpand NOT found on the builder's system, then build a
gnuplot executable that will never call kpsexpand.
OR
(3) in the bugreport comment thread, somebody suggested a
--disable-kpsewhich configure option, but no patch was given
The gnuplot developers are not concerned with end-user experience; "if
it doesn't work the way you want, recompile it yourself". And people
say the cygwin list has a bad case of WJM!
As pointed out in the bugreport comment thread, the whole POINT of using
kps* programs is to defer the determination of path/filenames until
runtime, on the user's system. The two patches proposed above both make
determinations based on the builder's system, and simply hope that the
choice was the correct one for the user's system. (ditto the (3) comment).
Or maybe they're all infected with the gentoo disease, and assume
user==builder, and user!=builder is an excuse to act superior and flaunt
higher l33tn355 5k0r3z.
==============================
Okay, so what to do?
(a) custom cygwin patch for gnuplot/variable.c, on the lines of
(UNTESTED; but fixup stupid linewrapping before trying to apply):
- { "$`kpsewhich -expand-path=$HOMETEXMF`\\fonts\\type1!" },
- { "$`kpsewhich -expand-path=$TEXMFLOCAL`\\fonts\\type1!" },
- { "$`kpsewhich -expand-path=$TEXMFMAIN`\\fonts\\type1!" },
- { "$`kpsewhich -expand-path=$TEXMFDIST`\\fonts\\type1!" },
+ { "$`if kpsewhich --help >/dev/null 2>&1; then kpsewhich
-expand-path=$HOMETEXMF ; else echo nonexist ; fi`\\fonts\\type1!" },
+ { "$`if kpsewhich --help >/dev/null 2>&1; then kpsewhich
-expand-path=$TEXMFLOCAL ; else echo nonexist ; fi`\\fonts\\type1!" },
+ { "$`if kpsewhich --help >/dev/null 2>&1; then kpsewhich
-expand-path=$TEXMFMAIN ; else echo nonexist ; fi`\\fonts\\type1!" },
+ { "$`if kpsewhich --help >/dev/null 2>&1; then kpsewhich
-expand-path=$TEXMFDIST ; else echo nonexist ; fi`\\fonts\\type1!" },
...
- { "$`kpsexpand '$HOMETEXMF'`/fonts/type1!" },
- { "$`kpsexpand '$TEXMFLOCAL'`/fonts/type1!" },
- { "$`kpsexpand '$TEXMFMAIN'`/fonts/type1!" },
- { "$`kpsexpand '$TEXMFDIST'`/fonts/type1!" },
+ { "$`if kpsexpand dummy >/dev/null 2>&1; then kpsexpand
'$HOMETEXMF' ; else echo nonexist ; fi`/fonts/type1!" },
+ { "$`if kpsexpand dummy >/dev/null 2>&1; then kpsexpand
'$TEXMFLOCAL' ; else echo nonexist ; fi`/fonts/type1!" },
+ { "$`if kpsexpand dummy >/dev/null 2>&1; then kpsexpand
'$TEXMFMAIN' ; else echo nonexist ; fi`/fonts/type1!" },
+ { "$`if kpsexpand dummy >/dev/null 2>&1; then kpsexpand
'$TEXMFDIST' ; else echo nonexist ; fi`/fonts/type1!" },
This would not be cross-platform, because the "/dev/null" and IO
redirection is not supported everywhere. But I think it would solve
this problem, and allow us to remove 'tetex-bin' as a rrequires: of gnuplot.
(b) split the kpse* stuff out of tetex-bin into its own (set of?)
packages, and have gnuplot depend on THOSE and not the entire tetex
distro. This might be an easier way to go -- if Jan is willing.
--
Chuck
P.S. Jan, there's also some wierdness with the tetex packages:
tetex-bin contains "/usr/lib/libkpathsea.la~"
tetex-devel contains "/usr/lib/libkpathsea.dll.a" (which it should) but
does NOT contain "/usr/lib/libkpathsea.la"
however, libkpathsea4 contains /usr/bin/cygkpathsea-4.dll (which it
should) but also "/usr/lib/libkpathsea.la" (which should be in
tetex-devel along with the .dll.a file -- unless option (b) above is
chosen, in which case both files should go into a new libkpathsea-devel
package)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -