From: Alan W. I. <ir...@be...> - 2004-02-17 23:15:50
|
To PLplot testers and developers: I have just uploaded plplot-5.3.0.cvs.20040217.tar.gz (but not the detached digital signature which I am not set up to generate yet) to http://plplot.sourceforge.net/cvs-tarball/. This tarball was built directly from plplot CVS HEAD. No documentation is included with this tarball; use http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.0/ instead. The tools used to generate the tarball are autoconf-2.58, automake-1.7.9, and libtool-1.5 (the vanilla versions direct from http://ftp.gnu.org/gnu/autoconf/, http://ftp.gnu.org/gnu/automake/, and http://ftp.gnu.org/gnu/libtool/ with the appropriate digital signatures) and swig-1.3.21. That is just for information purposes; tarball users don't require autoconf, automake, libtool, and swig if they just stick to ./configure, make, make check, and make install. One change you should notice for this tarball is the default list of devices has been substantially reduced. Many of the ones which are no longer default are associated with old hardware that few (including the developers) can access or test. So for default configurations you should get faster builds and installs. Another change is "make check" should now work from the top-level build directory. It tests whether the examples executables can be built from the build tree, and also automatically generates postscript results for all examples. (These build-tree postscript results should be located in the test directory after make check is run.) The old method of testing the install tree examples (cd $prefix/share/plplot-5.3.0.cvs.20040217/examples; make; ./plplot-test.sh) should continue to work as well. I have just tested this tarball on a solaris system, and it passes with flying colours (both the build tree make check, and install tree make; ./plplot-test.sh.) The big Solaris news is the libplplotf77 linking complications should be a thing of the past, i.e., I needed absolutely no FLIBS (which on Solaris for my previous test was a nightmare list of a huge number of different -L and -l options). Indeed, FLIBS is now completely ignored. This confirms a result already found for Mac OS X by Koen for the last test tarball and should make it much easier to build and install PLplot on other Unix platforms. Since the last test tarball (generated by Rafael in that case) I have also substantially changed the Java and Python interface linking, and the linking of gd.la. The results should be more robust now and therefore work on a wider variety of platforms, but the Solaris system on which I just tested plplot-5.3.0.cvs.20040217.tar.gz had no Java, Python, or libgd so these new linking changes have so far only been tested on Linux. That's where you cross-platform testers come in.... Anyhow, please test plplot-5.3.0.cvs.20040217.tar.gz and report back to the list. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-18 00:34:21
|
On Feb 17, 2004, at 6:07 PM, Alan W. Irwin wrote: > To PLplot testers and developers: > > I have just uploaded plplot-5.3.0.cvs.20040217.tar.gz (but not the > detached > digital signature which I am not set up to generate yet) to > http://plplot.sourceforge.net/cvs-tarball/. Just tried it out. On one Mac with a minimal number of additional packages (no python, tcltk, g77, etc) installation went smooth. On another Mac with all the needed packages configuration had a lot of problems: 1. GDLIBDIR is not honored anymore, so gd, etc are disabled 2. I now get a message that 'swig' is not installed. Is this a new dependency? 3. makefiles are not generated because of many lines like this: configure: creating ./config.status config.status: creating Makefile sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside substitute pattern config.status: creating src/Makefile sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside substitute pattern config.status: creating include/Makefile sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside substitute pattern > One change you should notice for this tarball is the default list of > devices > has been substantially reduced. From 5 MB to 2.9 MB indeed is a big reduction, especially when you're on dialup (like me ;) - Koen. |
From: Alan W. I. <ir...@be...> - 2004-02-18 01:32:39
|
On 2004-02-17 19:29-0500 Koen van der Drift wrote: > > On Feb 17, 2004, at 6:07 PM, Alan W. Irwin wrote: > > > To PLplot testers and developers: > > > > I have just uploaded plplot-5.3.0.cvs.20040217.tar.gz (but not the > > detached > > digital signature which I am not set up to generate yet) to > > http://plplot.sourceforge.net/cvs-tarball/. > > Just tried it out. On one Mac with a minimal number of additional > packages (no python, tcltk, g77, etc) installation went smooth. On > another Mac with all the needed packages configuration had a lot of > problems: > > 1. GDLIBDIR is not honored anymore, so gd, etc are disabled I just tried that here and there are absolutely no problems. Could you please give more specifics (captured .configure output, config.log, etc.)? Look very carefully at "ls $GDLIBDIR" results to make sure libgd.la is actually in the GDLIBDIR directory location that you are specifying. > 2. I now get a message that 'swig' is not installed. Is this a new > dependency? No. If that is just a warning message, just ignore it since tarball users don't need swig. However, if on the contrary it is a showstopper error where everything grinds to a halt, then we will have to re-assess. > 3. makefiles are not generated because of many lines like this: > > configure: creating ./config.status > config.status: creating Makefile > sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside > substitute pattern > config.status: creating src/Makefile > sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside > substitute pattern > config.status: creating include/Makefile > sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside > substitute pattern Those messages are completely new to me. I suspect you have a bad shell or bad sed on that system. Has plplot ever worked on that system where you are now having difficulties? Have you recently updated /bin/sh or /bin/sed there? The configure script uses whatever is in /bin/sh for the shell. Is that the same file on the system where PLplot works and the system where it doesn't? Same question for sed. Find the location of sed with the command "which sed". To find if they are identical files look at their lengths with "ls -l", and compare them bit for bit with cmp or diff. Alternatively, this could be our fault with some inadvertent extensions to sed use that won't work cross-platform. But we are normally pretty careful about that, and the above error message is less than informative about where the problem might be. Assuming it is not a system problem but is instead a newly introduced PLplot problem, could you run ./configure --your_options.... >& configure.out" and send us configure.out as an attachment? Also could you send config.log as an attachment? Those two files should help us narrow down where the error is first occurring, and help us to find the source of the problem. Also, on your system where things went smoothly, you might want to add in packages one by one until you find the one causing the problem. > > > One change you should notice for this tarball is the default list of > > devices > > has been substantially reduced. > > From 5 MB to 2.9 MB indeed is a big reduction, especially when you're > on dialup (like me ;) A smaller number of default devices should make no difference to the size of the source files in the tarball. Presumably what you are seeing is the effects of not having the documentation in the tarball because I couldn't build the documentation. So I will take credit for that.... :-) Thanks, Koen, for your testing help and especially for your patience with any cross-platform bugs that we introduce with our improvements. Two steps forward, one back..... Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-18 02:39:32
Attachments:
20040217.tar.gz
20040214.tar.gz
|
On Feb 17, 2004, at 8:27 PM, Alan W. Irwin wrote: >> Just tried it out. On one Mac with a minimal number of additional >> packages (no python, tcltk, g77, etc) installation went smooth. On >> another Mac with all the needed packages configuration had a lot of >> problems: >> >> 1. GDLIBDIR is not honored anymore, so gd, etc are disabled > > I just tried that here and there are absolutely no problems. Could you > please give more specifics (captured .configure output, config.log, > etc.)? > Look very carefully at "ls $GDLIBDIR" results to make sure libgd.la is > actually in the GDLIBDIR directory location that you are specifying. I am using the exact same configure parameters as before, so GDLIBDIR is pointing to the gd libs in /sw/lib >> 3. makefiles are not generated because of many lines like this: >> >> configure: creating ./config.status >> config.status: creating Makefile >> sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside >> substitute pattern >> config.status: creating src/Makefile >> sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside >> substitute pattern >> config.status: creating include/Makefile >> sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside >> substitute pattern > > Those messages are completely new to me. I suspect you have a bad > shell or > bad sed on that system. Has plplot ever worked on that system where > you are > now having difficulties? This is the same system I have done all plplot testing on before. I just tried the cvs tarball from 02/14 again, and that one went smoothly, using the same fink info file (to make sure the configure parameters are exactly the same). I have attached the configure.out and config.log files for both tarballs (20040214 and 20040217), and will try out your other suggestions later. - Koen. |
From: Rafael L. <rla...@us...> - 2004-02-18 06:51:11
|
* Koen van der Drift <kvd...@ea...> [2004-02-17 21:34]: > This is the same system I have done all plplot testing on before. I > just tried the cvs tarball from 02/14 again, and that one went > smoothly, using the same fink info file (to make sure the configure > parameters are exactly the same). I have attached the configure.out and > config.log files for both tarballs (20040214 and 20040217), and will > try out your other suggestions later. Could you please send the config.status file obtained with the 20040217 tarball? -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-18 11:11:01
Attachments:
config.status
|
On Feb 18, 2004, at 1:46 AM, Rafael Laboissiere wrote: > > Could you please send the config.status file obtained with the 20040217 > tarball? > see attachement. - Koen. |
From: Rafael L. <rla...@us...> - 2004-02-18 12:26:26
|
* Koen van der Drift <kvd...@ea...> [2004-02-18 06:05]: > On Feb 18, 2004, at 1:46 AM, Rafael Laboissiere wrote: > > > Could you please send the config.status file obtained with the 20040217 > > tarball? > > see attachement. Thanks, Koen, that was very useful. Indeed, I found the culprit, which are the following two lines in your config.status: s,@PYTHON_LDFLAGS@,-L/sw/lib/python2.3/config//libpython2.3.a /sw/lib/python2.3/config/ -lpython2.3,;t t Apparently, the use of the macro PYTHON_DEVEL in configure conpletely screwed up the AC_SUBSTitution of PYTHON_LDFLAGS on MacOS X. So, the problem is not with your sed or your shell as it was suggested, but actually on PLplot's side. I do not have time to find a fix for this, it will have to wait until the next weekend, at least (unless Alan take some action). We can say that the last CVS tarball is severily broken for MacOS X. [ For the curious: how did I find the bug? Starting from Koen's report: sed: 28: ./confstatX2964H/subs-3.sed: unescaped newline inside substitute pattern I then run "./config.status --debug Makefile" and look around line 28 of the file confstat??????/subs-3.sed. Easy, isn't it? ;-) ] -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-18 19:39:22
|
On 2004-02-18 13:21+0100 Rafael Laboissiere wrote: > * Koen van der Drift <kvd...@ea...> [2004-02-18 06:05]: > > > On Feb 18, 2004, at 1:46 AM, Rafael Laboissiere wrote: > > > > > Could you please send the config.status file obtained with the 20040217 > > > tarball? > > > > see attachement. > > Thanks, Koen, that was very useful. Indeed, I found the culprit, which are > the following two lines in your config.status: > > s,@PYTHON_LDFLAGS@,-L/sw/lib/python2.3/config//libpython2.3.a > /sw/lib/python2.3/config/ -lpython2.3,;t t > > Apparently, the use of the macro PYTHON_DEVEL in configure conpletely > screwed up the AC_SUBSTitution of PYTHON_LDFLAGS on MacOS X. Thanks, Rafael, for narrowing down the source of the problem on MacOS X. It appears python_path gets completely screwed up on that system. It should be /sw/lib/python2.3/config/ (with no embedded carriage return) rather than the current /sw/lib/python2.3/config//libpython2.3.aCR/sw/lib/python2.3/config/ The configure file has the following lines in it PYTHON_LDFLAGS="-L$python_path -lpython$PYTHON_VERSION" s,@PYTHON_LDFLAGS@,$PYTHON_LDFLAGS,;t t Koen, if you edit configure and change that first line to PYTHON_LDFLAGS="-L/sw/lib/python2.3/config/ -lpython$PYTHON_VERSION" (in other words, replace the bad python_path returned by PYTHON_DEVEL on your system with the correct value), does everything else work fine? Note that the PYTHON_DEVEL macro (which was simply copied from swig.m4 from the swig developers) works fine on Linux, and I also just received a report from Ullah, that it works fine on Cygwin. So fundamentally, it is working properly, but there is some cross-platform bug specific to MacOS X. I am not an m4 expert, and the macro code looks a bit complicated so I am going to let Rafael sort this out when he has the chance. But once he figures out how to get python_path reported properly on Mac OS X, I will report the cross-platform bug to the swig team. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-02-18 20:32:27
|
On 2004-02-18 11:25-0800 Alan W. Irwin wrote: I just realized the source of the problem in the macro. The following line is there: python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print` but the subsequent logic gets screwed if the find command finds more than one real file which satisfies that wildcarded name. Apparently, MacOSX does have two files which satisfy the criterion and this causes the problem. One solution would be to loop through the resulting files returned by the find. I will work on that and probably commit it, but Rafael, if you find a more elegant way to fix the two-or-more file problem, go ahead and make your own commit. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-19 00:42:22
|
On Feb 18, 2004, at 3:23 PM, Alan W. Irwin wrote: > but the subsequent logic gets screwed if the find command finds more > than > one real file which satisfies that wildcarded name. Apparently, MacOSX > does have two files which satisfy the criterion and this causes the > problem. > Which makes sense, because I have the original python that came with Mac OS X, plus the more recent version that comes with fink. - Koen. |
From: Rafael L. <rla...@us...> - 2004-02-18 22:08:13
|
* Alan W. Irwin <ir...@be...> [2004-02-18 12:23]: > On 2004-02-18 11:25-0800 Alan W. Irwin wrote: > > I just realized the source of the problem in the macro. > > The following line is there: > > python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print` > > but the subsequent logic gets screwed if the find command finds more than > one real file which satisfies that wildcarded name. Apparently, MacOSX > does have two files which satisfy the criterion and this causes the > problem. > > One solution would be to loop through the resulting files returned by the > find. I will work on that and probably commit it, but Rafael, if you find a > more elegant way to fix the two-or-more file problem, go ahead and make your > own commit. What about replacing the line above by: python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print | sed 1q` The "sed 1q" command at the end should be widely portable. For instance, it appears a couple of times in configure. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-18 22:16:20
|
I have just fixed a macro problem in cvs. The problem is the for i loops after the find commands cannot handle the multi-line results from those find commands when more than one file is found. The solution is to replace by a while loop with the appropriate test. Koen, will you please try the following patch to the _original_ unedited configure file that you get from the tarball? --- ../tarballs/plplot-5.3.0.cvs.20040217/configure Tue Feb 17 11:04:09 2004 +++ ./configure Wed Feb 18 13:40:35 2004 @@ -21379,9 +21379,8 @@ break fi done - for i in $python_path ; do + while test "$python_path" != "${python_path%/Python.h}"; do python_path=${python_path%/Python.h} - break done echo "$as_me:$LINENO: result: $python_path" >&5 echo "${ECHO_T}$python_path" >&6 @@ -21402,9 +21401,8 @@ break fi done - for i in $python_path ; do + while test "$python_path" != "${python_path%/libpython*}"; do python_path=${python_path%/libpython*} - break done echo "$as_me:$LINENO: result: $python_path" >&5 echo "${ECHO_T}$python_path" >&6 @@ -25747,7 +25745,7 @@ # Provide some information about the compiler. -echo "$as_me:25750:" \ +echo "$as_me:25748:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5 Koen, in case you don't understand patches, this context diff means that you find the relevant "-" lines and delete them from your file, and similarly add the relevant + lines. So there are only 7 lines you need to change, and I don't think it is worth re-issuing the tarball for such a small change. For Joao and Don, this is a rather extreme corner case (more than one file found by those find commands) that is unlikely to happen on your system so it is probably fine to test the current tarball without the above patch on OSF1 and AIX. Note, Cygwin (with dyndrivers disabled), Linux, and Solaris tests of the tarball are fine. In particular FLIBS no longer needs to be specified on any platform (in fact it is ignored), and on Cygwin, Ullal reports the python linking works well for the first time thanks to the recent python linking changes. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-19 00:35:50
|
Alan, > Koen, in case you don't understand patches, this context diff means > that you > find the relevant "-" lines and delete them from your file, and > similarly > add the relevant + lines. So there are only 7 lines you need to > change, and > I don't think it is worth re-issuing the tarball for such a small > change. Yes, that fixed the problem, and ./configure finished without problems (except for the gd problem). - Koen. |
From: Alan W. I. <ir...@be...> - 2004-02-19 01:52:28
|
On 2004-02-18 19:30-0500 Koen van der Drift wrote: > > Alan, > > > > Koen, in case you don't understand patches, this context diff means > > that you > > find the relevant "-" lines and delete them from your file, and > > similarly > > add the relevant + lines. So there are only 7 lines you need to > > change, and > > I don't think it is worth re-issuing the tarball for such a small > > change. > > > Yes, that fixed the problem, and ./configure finished without problems Great! So we now have good results for Linux, Solaris, Cygwin, and Mac OS X > (except for the gd problem). That little qualifier is not so great, but we should be able to sort it out once you give us some more data. I must have made some mistake in my few changes to the libgd handling, but I have stared at my changes, and I cannot see where the problem must be. Also, I have tested the use of GDLIBDIR for Linux, and it works fine for that case. Thus, I need more data from you. Please execute (by hand rather than script) export GDLIBDIR=/path/to/libgd.*/ then run ./configure and send us the resulting config.log and the captured configure output. Also, please show the contents of the $GDLIBDIR directory by giving the result of ls $GDLIBDIR/libgd.* Also, what is the result of grep GD Makefile in the top of your build tree after the ./configure step? Thanks. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-19 02:38:08
|
On Feb 18, 2004, at 8:47 PM, Alan W. Irwin wrote: > That little qualifier is not so great, but we should be able to sort it > out once you give us some more data. I solved that one. The actual problem was that the gd headers could not be found. So I added GDINCDIR to my configure parameters, and now it worked. I never used that before (no need for, the headers were found without it), so I am not sure why it went wrong this time. I tested it too with the 5.3.0 release version, and it still finds the headers without GDINCDIR. - Koen. |
From: Rafael L. <rla...@us...> - 2004-02-20 08:48:54
|
* Koen van der Drift <kvd...@ea...> [2004-02-18 21:32]: > On Feb 18, 2004, at 8:47 PM, Alan W. Irwin wrote: > >That little qualifier is not so great, but we should be able to sort it > >out once you give us some more data. > > I solved that one. The actual problem was that the gd headers could not > be found. So I added GDINCDIR to my configure parameters, and now it > worked. I never used that before (no need for, the headers were found > without it), so I am not sure why it went wrong this time. I tested it > too with the 5.3.0 release version, and it still finds the headers > without GDINCDIR. This is puzzling. If I do: cvs diff -u -r v5_3_0 -r HEAD sysloc.in I see that there has been no change releated to GCINCDIR since the 5.3.0 release. Unless some recent change to sysloc.in has some obscure side effect. Alan? -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-20 16:28:55
|
On 2004-02-20 09:42+0100 Rafael Laboissiere wrote: > * Koen van der Drift <kvd...@ea...> [2004-02-18 21:32]: > > > On Feb 18, 2004, at 8:47 PM, Alan W. Irwin wrote: > > >That little qualifier is not so great, but we should be able to sort it > > >out once you give us some more data. > > > > I solved that one. The actual problem was that the gd headers could not > > be found. So I added GDINCDIR to my configure parameters, and now it > > worked. I never used that before (no need for, the headers were found > > without it), so I am not sure why it went wrong this time. I tested it > > too with the 5.3.0 release version, and it still finds the headers > > without GDINCDIR. > > This is puzzling. If I do: > > cvs diff -u -r v5_3_0 -r HEAD sysloc.in > > I see that there has been no change releated to GCINCDIR since the 5.3.0 > release. Unless some recent change to sysloc.in has some obscure side > effect. Alan? It puzzles me also, but I am not going to worry about it since I cannot reproduce the bug on my system. In any case, we are soon (I hope) going to move to configure options to specify needed special directory locations which means bugs in our present environment variable way of doing this will be moot. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Koen v. d. D. <kvd...@ea...> - 2004-02-20 20:42:39
|
On Feb 20, 2004, at 11:22 AM, Alan W. Irwin wrote: > It puzzles me also, but I am not going to worry about it since I cannot > reproduce the bug on my system. In any case, we are soon (I hope) > going to > move to configure options to specify needed special directory locations > which means bugs in our present environment variable way of doing this > will > be moot. > > It could be some weird thing on my system :) Anyway, could you remind me when the next release is up that I write an update for installing plplot on Mac OS X? - Koen. |
From: Rafael L. <rla...@us...> - 2004-02-19 21:00:26
|
* Alan W. Irwin <ir...@be...> [2004-02-18 14:08]: > I have just fixed a macro problem in cvs. > > The problem is the for i loops after the find commands cannot handle the > multi-line results from those find commands when more than one file > is found. The solution is to replace by a while loop with the appropriate > test. > > Koen, will you please try the following patch to the _original_ unedited > configure file that you get from the tarball? > > --- ../tarballs/plplot-5.3.0.cvs.20040217/configure Tue Feb 17 11:04:09 2004 > +++ ./configure Wed Feb 18 13:40:35 2004 > @@ -21379,9 +21379,8 @@ > break > fi > done > - for i in $python_path ; do > + while test "$python_path" != "${python_path%/Python.h}"; do > python_path=${python_path%/Python.h} > - break > done > echo "$as_me:$LINENO: result: $python_path" >&5 > echo "${ECHO_T}$python_path" >&6 > @@ -21402,9 +21401,8 @@ > break > fi > done > - for i in $python_path ; do > + while test "$python_path" != "${python_path%/libpython*}"; do > python_path=${python_path%/libpython*} > - break > done > echo "$as_me:$LINENO: result: $python_path" >&5 > echo "${ECHO_T}$python_path" >&6 I do not quite understand what your code above is intended to do. I do not understand neither the original code (the variable i is not used in the for loop, for instance). At any rate, your fix does not work here. Try the following experiment: [as root] # mkdir /usr/include/python2.3/bogus # touch /usr/include/python2.3/bogus/Python.h [not necessarily as root] $ ./configure [...] configure: creating ./config.status config.status: creating Makefile sed: file ./confstatNI0lhL/subs-3.sed line 28: Unterminated `s'command config.status: creating src/Makefile sed: file ./confstatNI0lhL/subs-3.sed line 28: Unterminated `s'command config.status: creating include/Makefile [...] $ fgrep /usr/include/python ./confstatNI0lhL/subs-3.sed s,@PYTHON_CPPFLAGS@,-I/usr/include/python2.3/Python.h /usr/include/python2.3/bogus,;t t In other words, I can replicate Koen's problem here, even after cvs update acinclude.m4. It happens that the patch below to the original swig.m4 file fixes the bug for me, even with the bogus/Python.h file present as above. Please confirm the problem and I will cvs commit the changes. --- swig.m4-orig 2004-02-19 21:52:01.000000000 +0100 +++ swig.m4 2004-02-19 21:52:10.000000000 +0100 @@ -89,7 +89,7 @@ AC_MSG_CHECKING([for Python include path]) python_path=${PYTHON%/bin*} for i in "$python_path/include/python$PYTHON_VERSION/" "$python_path/include/python/" "$python_path/" ; do - python_path=`find $i -type f -name Python.h -print` + python_path=`find $i -type f -name Python.h -print | sed 1q` if test -n "$python_path" ; then break fi @@ -108,7 +108,7 @@ AC_MSG_CHECKING([for Python library path]) python_path=${PYTHON%/bin*} for i in "$python_path/lib/python$PYTHON_VERSION/config/" "$python_path/lib/python$PYTHON_VERSION/" "$python_path/lib/python/config/" "$python_path/lib/python/" "$python_path/" ; do - python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print` + python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print | sed 1q` if test -n "$python_path" ; then break fi -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-19 22:40:18
|
On 2004-02-19 21:54+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-02-18 14:08]: > > > I have just fixed a macro problem in cvs. > > > > The problem is the for i loops after the find commands cannot handle the > > multi-line results from those find commands when more than one file > > is found. The solution is to replace by a while loop with the appropriate > > test. > > - for i in $python_path ; do > > + while test "$python_path" != "${python_path%/Python.h}"; do > > python_path=${python_path%/Python.h} > > - break > > done > > - for i in $python_path ; do > > + while test "$python_path" != "${python_path%/libpython*}"; do > > python_path=${python_path%/libpython*} > > - break > > done > > I do not quite understand what your code above is intended to do. I think a modification of your code is much better from a cross-platform perspective, see below, but to answer your question each iteration of the /libpython* while loop chops off trailing /libpython* characters until further attempts to chop off /libpython* doesn't do anything. Note, there is a bug in the above (which you just found.) There should be an asterisk after /Python.h. But I don't care any more (see below). > It happens that the patch below to the original swig.m4 file fixes the bug > for me, even with the bogus/Python.h file present as above. Please confirm > the problem and I will cvs commit the changes. > > > --- swig.m4-orig 2004-02-19 21:52:01.000000000 +0100 > +++ swig.m4 2004-02-19 21:52:10.000000000 +0100 > @@ -89,7 +89,7 @@ > AC_MSG_CHECKING([for Python include path]) > python_path=${PYTHON%/bin*} > for i in "$python_path/include/python$PYTHON_VERSION/" "$python_path/include/python/" "$python_path/" ; do > - python_path=`find $i -type f -name Python.h -print` > + python_path=`find $i -type f -name Python.h -print | sed 1q` > if test -n "$python_path" ; then > break > fi > @@ -108,7 +108,7 @@ > AC_MSG_CHECKING([for Python library path]) > python_path=${PYTHON%/bin*} > for i in "$python_path/lib/python$PYTHON_VERSION/config/" "$python_path/lib/python$PYTHON_VERSION/" "$python_path/lib/python/config/" "$python_path/lib/python/" "$python_path/" ; do > - python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print` > + python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print | sed 1q` > if test -n "$python_path" ; then > break > fi The sed "1q" solution will work fine on Linux and Solaris (just tried it), and I am going to assume that is a good cross-platform way to get the first file name found by find. But then the subsequent loop is useless and, e.g., for i in $python_path ; do python_path=${python_path%/Python.h} break done Should just be replaced by python_path=${python_path%/Python.h} or better yet(from the cross-platform perspective since the %/Python.h construct is a bashism) python_path=`echo $python_path |sed "s,/Python.h$,,"` Let me work on this in a consistent way. I now think there is good hope to update the swig.m4 macros to work correctly on most (all?) Unix platforms for the multi-file case. That would be a big step forward for us and also the swig package. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2004-02-20 01:36:12
|
On 2004-02-19 14:34-0800 Alan W. Irwin wrote: > python_path=`echo $python_path |sed "s,/Python.h$,,"` (etc.) > > Let me work on this in a consistent way. I now think there is good hope to > update the swig.m4 macros to work correctly on most (all?) Unix platforms > for the multi-file case. That would be a big step forward for us and also > the swig package. Hi Rafael: I think I have reached that goal of a good cross-platform swig.m4 solution (which I have committed as part of our acinclude.m4). It produces identical SWIG and PYTHON variables in the Makefile's that I had before. Will you have a close detailed look at my changes (some of which are not exercised by PLplot but which I want to submit to the swig team in any case), and also try some of your pathological tests that broke everything for the previous multi-file bug solution? If it works for you, I think we can say CVS HEAD is in pretty good shape. I tested a lot of the recent Makefile.am changes earlier today (but not some recent changes in the last hour), and all was well. I suggest it is nearly time to produce another test tarball from CVS HEAD. (I sense there are still a few more dependency changes you want to make for CVS HEAD, but that is about it.) I assume it will be really easy for you to make the tarball with the -n option, but if you prefer me to do it instead, let me know when you are ready. Have you got the fix in place so that we can make the tarball in the build tree? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-02-20 07:06:24
|
* Alan W. Irwin <ir...@be...> [2004-02-19 17:30]: > I suggest it is nearly time to produce another test tarball from CVS HEAD. > (I sense there are still a few more dependency changes you want to make for > CVS HEAD, but that is about it.) I assume it will be really easy for you to > make the tarball with the -n option, but if you prefer me to do it instead, > let me know when you are ready. I do not care one way or the other but if you do, please, provide a dummy GPG key number to the upload-cvs-tarball.sh script. The one that appears currently in http://plplot.sourceforge.net/cvs-tarball/ is mine, but that is wrong. This is also valid for the other developpers that do not sign the uploaded tarball. > Have you got the fix in place so that we can make the tarball in the build > tree? In principle, the fix is quite simple, just a call to the macro AC_CONFIG_AUX_DIR. However, I have to check for side effects and this may take some time. In the meanwhile, just build your tarball away from the build tree, say in /tmp. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-20 17:16:25
|
On 2004-02-20 08:00+0100 Rafael Laboissiere wrote: > [....]please, provide a dummy > GPG key number to the upload-cvs-tarball.sh script. The one that appears > currently in http://plplot.sourceforge.net/cvs-tarball/ is mine, but that is > wrong. This is also valid for the other developpers that do not sign the > uploaded tarball. Note, there was no detached signature so the practical consequences were nil, but nevertheless I agree it would be better not to have your key id associated with the no signature case, and in fact I wouldn't allow the no signature case (see below). Here is the solution to this problem that I would recommend. Rafael, please change your script to test the exit status of the gpg signing attempt and only proceed with the upload if the gpg signing succeeded. As I have reason to know, that key signing fails and no signature file is produced if the key does not belong to you. That script change will solve your concern that your key id will inappropriately be put on the website and will also force everybody who wants to use the convenience of the script to provide a correct key id number that belongs to them. That encouragement is worthwhile because the resulting detached signature provides a convenient check for the user that there haven't been any transmission errors. Also, there is some security benefit from generating an electronic signature that is unique to the combination of the individual that signed the tarball and the exact bit pattern of the tarball. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-02-19 21:41:01
|
* Alan W. Irwin <ir...@be...> [2004-02-17 17:27]: > > 2. I now get a message that 'swig' is not installed. Is this a new > > dependency? > > No. If that is just a warning message, just ignore it since tarball users > don't need swig. However, if on the contrary it is a showstopper error > where everything grinds to a halt, then we will have to re-assess. I found a way to get the same behavior as before, i.e. no warnings if swig is not found. The patch is below. Should I commit it, Alan? --- configure.ac 17 Feb 2004 02:25:00 -0000 1.165 +++ configure.ac 19 Feb 2004 21:28:15 -0000 @@ -546,7 +546,9 @@ # swig only needed for python and java interface so far. if test "$enable_python" = "yes" -o "$enable_java" = "yes"; then + pushdef([AC_MSG_WARN],[true]) SWIG_PROG(1.3.21) + popdef([AC_MSG_WARN]) fi ### Create list of valid examples subdirectories -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-02-20 02:11:15
|
On 2004-02-19 22:35+0100 Rafael Laboissiere wrote: > I found a way to get the same behavior as before, i.e. no warnings if swig > is not found. The patch is below. Should I commit it, Alan? > > --- configure.ac 17 Feb 2004 02:25:00 -0000 1.165 > +++ configure.ac 19 Feb 2004 21:28:15 -0000 > @@ -546,7 +546,9 @@ > > # swig only needed for python and java interface so far. > if test "$enable_python" = "yes" -o "$enable_java" = "yes"; then > + pushdef([AC_MSG_WARN],[true]) > SWIG_PROG(1.3.21) > + popdef([AC_MSG_WARN]) > fi > > ### Create list of valid examples subdirectories First let us talk about the status quo for cvs developers. I looked in the swig version check in acinclude.m4, and all it does is warn which is not enough. Rafael, do you agree that should be changed to include something like the following line to redefine SWIG: SWIG='echo "SWIG version $1 is required, you have $swig_version. You may have a look at http://www.swig.org" ; false' This redefinition is essential so that cvs developers don't use the wrong version of swig which would lead to tough-to-decipher Python and Java errors. If you agree this is the right thing to do, I will commit the change to acinclude.m4. (Actually it is changes; we need SWIG redefined to a different message when the swig version cannot be determined.) Once the SWIG redefinitions are in place to stop SWIG use at make time for the wrong version case, then I think suppressing the additional configuration time warning messages as above is fine since cvs developers won't need that early warning, and they just confuse tarball users. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |