X-Spam-Check-By: sourceware.org Message-ID: <4556C648.5030905@cwilson.fastmail.fm> Date: Sun, 12 Nov 2006 01:59:20 -0500 From: Charles Wilson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: gnuplot and tex Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/