From: Alan W. I. <ir...@be...> - 2004-11-05 01:18:31
|
Warning: it appears swig 1.3.22 is backwards incompatible with previous versions of swig and also our current cvs version of PLplot. 1.3.22 has been out now since 2004-09-03 and has propagated, for example to Debian testing. The symptom you will see if you attempt to build PLplot from raw cvs with this latest swig version is the plplotcmodule_double.c source file will have lots of compilation errors. (My compilations never reached to the java stage so I don't know whether there would be additional errors in that case as well for swig-1.3.22.) The workaround is to stick strictly with swig-1.3.21 until one of us has a chance to find what is incompatible with the new swig version and fix it. I am the obvious "volunteer" to fix this, but I am busy doing other things at the moment so this complete fix is going to be delayed quite a while (probably months) unless somebody else steps forward. Meanwhile, the workaround of continuing to use swig-1.3.21 should not be a major difficulty for anybody since it is available from http://sourceforge.net/project/showfiles.php?group_id=1645 if your Linux distribution does not have this exact version. Note this note is relevant only for those who build from our raw cvs version. Rafael has been careful to build our latest cvs snapshot tarball that is available at http://plplot.sourceforge.net/cvs-tarball/ using swig-1.3.21 so there are no problems in that case. 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
Re: [Plplot-devel] Warning about swig-1.3.22 for those that build from the raw cvs version of PLplot
From: Andrew R. <and...@us...> - 2004-11-09 18:14:48
|
On Thu, Nov 04, 2004 at 05:18:19PM -0800, Alan Irwin wrote: > Warning: it appears swig 1.3.22 is backwards incompatible with previous > versions of swig and also our current cvs version of PLplot. 1.3.22 has > been out now since 2004-09-03 and has propagated, for example to Debian > testing. The symptom you will see if you attempt to build PLplot from raw > cvs with this latest swig version is the plplotcmodule_double.c source file > will have lots of compilation errors. (My compilations never reached to the > java stage so I don't know whether there would be additional errors in that > case as well for swig-1.3.22.) > I've looked into this a little bit more. Firstly the good news - java seems to be unaffected and works fine with swig-1.3.22. There are two sources of errors in the python bindings. One is code like static PyObject *_wrap_pltr0(PyObject *, PyObject *args) { ... } Omitting the function parameter name for an unused argument is legal in C++ but not so far as I know in C. This appears to be because we are using the -c++ option to swig, but are not compiling the resulting wrapper with a c++ compiler. Removing -c++ seems to fix the problem. This option was not present for java anyway. The other error is in the SwigMethod array. This is modified by makedocstrings.py to create plplotcmodule_double.c from plplotcmodule_p_double.c. This fixes the documentation handling which is broken in swig. Looks like the handling of this section has changed. Swig now adds the NULL parameter in for the document string. makedocstrings.py just tacks our documentation string onto the end of this array rather than replacing the NULL with our string. I'm not a python expert, however I think I have successfully hacked the makedocstrings.py script to work with swig 1.3.21 and 1.3.22. It compiles ok for me with both and the examples seem to work. Perhaps someone else has a more elegant solution. Please test this to make sure it doesn't break on your system. Cheers Andrew I noticed in testing that "make check" still doesn't work for python in a separate build tree. |
Re: [Plplot-devel] Warning about swig-1.3.22 for those that build from
the raw cvs version of PLplot
From: Alan W. I. <ir...@be...> - 2004-11-09 21:07:05
|
On 2004-11-09 18:14-0000 Andrew Ross wrote: > On Thu, Nov 04, 2004 at 05:18:19PM -0800, Alan Irwin wrote: >> Warning: it appears swig 1.3.22 is backwards incompatible with previous >> versions of swig and also our current cvs version of PLplot. 1.3.22 has >> been out now since 2004-09-03 and has propagated, for example to Debian >> testing. The symptom you will see if you attempt to build PLplot from raw >> cvs with this latest swig version is the plplotcmodule_double.c source file >> will have lots of compilation errors. (My compilations never reached to the >> java stage so I don't know whether there would be additional errors in that >> case as well for swig-1.3.22.) >> > > I've looked into this a little bit more. Firstly the good news - java > seems to be unaffected and works fine with swig-1.3.22. > > There are two sources of errors in the python bindings. One is code like > > static PyObject *_wrap_pltr0(PyObject *, PyObject *args) { > ... > } > > Omitting the function parameter name for an unused argument is legal in > C++ but not so far as I know in C. This appears to be because we are > using the -c++ option to swig, but are not compiling the resulting > wrapper with a c++ compiler. Removing -c++ seems to fix the problem. Thanks, Andrew for looking into this. I copied that -c++ option from Gary Bishop's work and didn't think too much about it since it worked, but since it now seems to make a (bad) difference, I am glad you have removed it. > > The other error is in the SwigMethod array. This is modified by > makedocstrings.py to create plplotcmodule_double.c from > plplotcmodule_p_double.c. This fixes the documentation handling which is > broken in swig. Looks like the handling of this section has > changed. Swig now adds the NULL parameter in for the document string. > makedocstrings.py just tacks our documentation string onto the end of > this array rather than replacing the NULL with our string. I'm not a > python expert, however I think I have successfully hacked the > makedocstrings.py script to work with swig 1.3.21 and 1.3.22. It > compiles ok for me with both and the examples seem to work. Perhaps > someone else has a more elegant solution. I am not much of a python expert (although I would like to be!), but your cvs change seems okay to me by visual inspection. I haven't had a chance to try your changes, but I assume they will work fine for me since we both have Debian testing systems. So, thanks very much for your efforts! > > I noticed in testing that "make check" still doesn't work for python in > a separate build tree. I believe the solution is to conditionally (when we have a separate build tree) make at build time the required symlinks from the build tree back to the source tree. One possibility for implementing this is to adapt what was done in the examples/tk/Makefile.am file which generates required symlinks to the tcl examples. However, it is possible there may be a more elegant way to make symlinks at build time. Rafael, could you please comment on the current examples/tk/Makefile.am symlink solution? 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
Re: [Plplot-devel] Warning about swig-1.3.22 for those that build from the raw cvs version of PLplot
From: Rafael L. <rla...@us...> - 2004-11-10 08:52:24
|
* Alan W. Irwin <ir...@be...> [2004-11-09 13:06]: > Rafael, could you please comment on the current examples/tk/Makefile.am > symlink solution? I am not familiar with the Tcl/Tk area of PLplot, sorry. However, if the symlink approach is working there, what would be wrong in using it elsewhere? -- Rafael |
Re: [Plplot-devel] Warning about swig-1.3.22 for those that build from
the raw cvs version of PLplot
From: Alan W. I. <ir...@be...> - 2004-11-10 18:19:18
|
On 2004-11-10 09:52+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-11-09 13:06]: > >> Rafael, could you please comment on the current examples/tk/Makefile.am >> symlink solution? > > I am not familiar with the Tcl/Tk area of PLplot, sorry. However, if the > symlink approach is working there, what would be wrong in using it > elsewhere? It has nothing to do with tcl/tk except that we need lots of symlinks established in examples/tk for files in examples/tcl. The Makefile.am segment in question is the following: ### x01.tcl stands symbolically for x??.tcl. If specify $(check_DATA) ### instead, then for loop below is usually incorrectly repeated for each file ### in check_DATA (depending on coarseness of timer). x01.tcl: \ $(top_srcdir)/examples/tcl/x01.tcl \ $(top_srcdir)/examples/tcl/x02.tcl \ $(top_srcdir)/examples/tcl/x03.tcl \ $(top_srcdir)/examples/tcl/x04.tcl \ $(top_srcdir)/examples/tcl/x05.tcl \ $(top_srcdir)/examples/tcl/x06.tcl \ $(top_srcdir)/examples/tcl/x07.tcl \ $(top_srcdir)/examples/tcl/x08.tcl \ $(top_srcdir)/examples/tcl/x09.tcl \ $(top_srcdir)/examples/tcl/x10.tcl \ $(top_srcdir)/examples/tcl/x11.tcl \ $(top_srcdir)/examples/tcl/x12.tcl \ $(top_srcdir)/examples/tcl/x13.tcl \ $(top_srcdir)/examples/tcl/x14.tcl \ $(top_srcdir)/examples/tcl/x15.tcl \ $(top_srcdir)/examples/tcl/x16.tcl \ $(top_srcdir)/examples/tcl/x17.tcl \ $(top_srcdir)/examples/tcl/x18.tcl \ $(top_srcdir)/examples/tcl/x19.tcl \ $(top_srcdir)/examples/tcl/x22.tcl ( cd $(top_srcdir)/examples/tcl ; \ for file in x??.tcl ; do \ rm -f $(BUILD_DIR)/examples/tk/$$file; $(LN_S) $(top_srcdir)/examples/tcl/$$file $(BUILD_DIR)/examples/tk/$$file ; \ done ) This logic can be cleaned up a bit further by using check_TCL = \ $(top_srcdir)/examples/tcl/x01.tcl \ $(top_srcdir)/examples/tcl/x02.tcl \ $(top_srcdir)/examples/tcl/x03.tcl \ $(top_srcdir)/examples/tcl/x04.tcl \ $(top_srcdir)/examples/tcl/x05.tcl \ $(top_srcdir)/examples/tcl/x06.tcl \ $(top_srcdir)/examples/tcl/x07.tcl \ $(top_srcdir)/examples/tcl/x08.tcl \ $(top_srcdir)/examples/tcl/x09.tcl \ $(top_srcdir)/examples/tcl/x10.tcl \ $(top_srcdir)/examples/tcl/x11.tcl \ $(top_srcdir)/examples/tcl/x12.tcl \ $(top_srcdir)/examples/tcl/x13.tcl \ $(top_srcdir)/examples/tcl/x14.tcl \ $(top_srcdir)/examples/tcl/x15.tcl \ $(top_srcdir)/examples/tcl/x16.tcl \ $(top_srcdir)/examples/tcl/x17.tcl \ $(top_srcdir)/examples/tcl/x18.tcl \ $(top_srcdir)/examples/tcl/x19.tcl \ $(top_srcdir)/examples/tcl/x22.tcl x01.tcl: $(check_TCL) ( cd $(top_srcdir)/examples/tcl ; \ for file in x??.tcl ; do \ rm -f $(BUILD_DIR)/examples/tk/$$file; $(LN_S) $(top_srcdir)/examples/tcl/$$file $(BUILD_DIR)/examples/tk/$$file ; \ done ) Obviously, we have to be more careful then this when we are establishing symlinks from the build directory to the source directory (because they are often the same directory), but we can get around that with the appropriate "if" statement I believe inside the for loop. It also still bothers me that the target must be one of the created symlinks, x01.tcl rather than the list of those symlinks. Also, I would like to make this logic more general by using a list rather than x??.tcl in the for loop, but I am not sure that is possible in a cross-platform way. Anyhow, Rafael, if you have any ideas for improving/generalizing this logic in a cross-platform way, please give us those ideas now. 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |
Re: [Plplot-devel] Warning about swig-1.3.22 for those that build from the raw cvs version of PLplot
From: Rafael L. <rla...@us...> - 2004-11-11 02:27:49
|
* Alan W. Irwin <ir...@be...> [2004-11-10 10:19]: > This logic can be cleaned up a bit further by using > > check_TCL = \ > $(top_srcdir)/examples/tcl/x01.tcl \ > $(top_srcdir)/examples/tcl/x02.tcl \ > $(top_srcdir)/examples/tcl/x03.tcl \ > $(top_srcdir)/examples/tcl/x04.tcl \ > $(top_srcdir)/examples/tcl/x05.tcl \ > $(top_srcdir)/examples/tcl/x06.tcl \ > $(top_srcdir)/examples/tcl/x07.tcl \ > $(top_srcdir)/examples/tcl/x08.tcl \ > $(top_srcdir)/examples/tcl/x09.tcl \ > $(top_srcdir)/examples/tcl/x10.tcl \ > $(top_srcdir)/examples/tcl/x11.tcl \ > $(top_srcdir)/examples/tcl/x12.tcl \ > $(top_srcdir)/examples/tcl/x13.tcl \ > $(top_srcdir)/examples/tcl/x14.tcl \ > $(top_srcdir)/examples/tcl/x15.tcl \ > $(top_srcdir)/examples/tcl/x16.tcl \ > $(top_srcdir)/examples/tcl/x17.tcl \ > $(top_srcdir)/examples/tcl/x18.tcl \ > $(top_srcdir)/examples/tcl/x19.tcl \ > $(top_srcdir)/examples/tcl/x22.tcl > > x01.tcl: $(check_TCL) > ( cd $(top_srcdir)/examples/tcl ; \ > for file in x??.tcl ; do \ > rm -f $(BUILD_DIR)/examples/tk/$$file; $(LN_S) > $(top_srcdir)/examples/tcl/$$file > $(BUILD_DIR)/examples/tk/$$file ; \ > done ) > > Obviously, we have to be more careful then this when we are establishing > symlinks from the build directory to the source directory (because they are > often the same directory), but we can get around that with the appropriate > "if" statement I believe inside the for loop. Why would this be necessary in the case above? After all, we are making simlinks in different directories (examples/tcl and examples/tk), which remain distinct even if $(top_srcdir) == $(BUILD_DIR). Am I misunderstanding what you wrote? > It also still bothers me that the target must be one of the created > symlinks, x01.tcl rather than the list of those symlinks. Also, I would > like to make this logic more general by using a list rather than x??.tcl in > the for loop, but I am not sure that is possible in a cross-platform way. What is wrong with this: $(check_DATA): \ $(top_srcdir)/examples/tcl/x01.tcl \ $(top_srcdir)/examples/tcl/x02.tcl \ $(top_srcdir)/examples/tcl/x03.tcl \ $(top_srcdir)/examples/tcl/x04.tcl \ $(top_srcdir)/examples/tcl/x05.tcl \ $(top_srcdir)/examples/tcl/x06.tcl \ $(top_srcdir)/examples/tcl/x07.tcl \ $(top_srcdir)/examples/tcl/x08.tcl \ $(top_srcdir)/examples/tcl/x09.tcl \ $(top_srcdir)/examples/tcl/x10.tcl \ $(top_srcdir)/examples/tcl/x11.tcl \ $(top_srcdir)/examples/tcl/x12.tcl \ $(top_srcdir)/examples/tcl/x13.tcl \ $(top_srcdir)/examples/tcl/x14.tcl \ $(top_srcdir)/examples/tcl/x15.tcl \ $(top_srcdir)/examples/tcl/x16.tcl \ $(top_srcdir)/examples/tcl/x17.tcl \ $(top_srcdir)/examples/tcl/x18.tcl \ $(top_srcdir)/examples/tcl/x19.tcl \ $(top_srcdir)/examples/tcl/x22.tcl for file in $(check_DATA) ; do \ rm -f $(BUILD_DIR)/examples/tk/$$file; \ $(LN_S) $(top_srcdir)/examples/tcl/$$file \ $(BUILD_DIR)/examples/tk/$$file ; \ done (Notice that the cd command is not necessary.) -- Rafael |
Re: [Plplot-devel] Warning about swig-1.3.22 for those that build from
the raw cvs version of PLplot
From: Alan W. I. <ir...@be...> - 2004-11-11 06:49:23
|
Thanks for your suggestions in the tk case. One other answer to your question below....Alan On 2004-11-11 03:27+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-11-10 10:19]: >> Obviously, we have to be more careful then this when we are establishing >> symlinks from the build directory to the source directory (because they are >> often the same directory), but we can get around that with the appropriate >> "if" statement I believe inside the for loop. > > Why would this be necessary in the case above? After all, we are making > simlinks in different directories (examples/tcl and examples/tk), which > remain distinct even if $(top_srcdir) == $(BUILD_DIR). Yes. > Am I > misunderstanding what you wrote? Yes, because my writing was ambiguous. Sorry about that! In this tk case, there is no problem as you said, but I was referring instead to the python case that started this thread. For separated build trees you need to make the symlink to a variety of required files in the source tree, but not when the build tree = source tree. To cover this situation, I was thinking of putting an if statement in the for loop such that you only make the symlink if the file does not already exist 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 FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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 __________________________ |