gnuplot and tex

[Charles Wilson]

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/