From: Alan W. I. <ir...@be...> - 2003-01-20 08:13:54
|
This is a quick announcement of the PLplot-5.2.0 release that has just occurred. The official announcement will come later this week when I will have more time to write it. Find the new release at http://sourceforge.net/project/showfiles.php?group_id=2915. There is a PLplot-5.2.0 tarball as well as RH7.3 source and binary rpms for PLplot-5.2.0 there. There have been paradigm shifts in our library organization and in our Linux/Unix configuration system which is now generated using autotools. So please hammer on PLplot-5.2.0 for as many Unix/Linux platforms as you have access to with the usual configure; make; make install. The best way to test is to cd $prefix/lib/plplot5.2.0/examples, execute make in each of the c, c++, f77, and tk subdirectories, then execute plplot-test.sh. "Works for me!" type reports with a clear description of your platform are most welcome. Of course, if you have problems please report back to plplot-devel with the detailed results of configure, make, and make install commands (and of course the description of your platform), and we will try to sort out what the problem is. There are bound to be some teething troubles with paradigm shifts like these, but PLplot-5.2.0 has been extensively tested on Linux systems and works well for them. Configuration systems built with autotools are designed to be platform-neutral so there is also good potential to be able to build and run PLplot-5.2.0 on a wide variety of other Unix platforms as well. So try it and see! To motivate you to try this new release, I should mention that the python and java interfaces to PLplot are now much more complete (thanks to swig). Also have a look at our new screenshots on http://plplot.sourceforge.net/examples/index.html (especially examples 8 and 11) to see what treats are in store for you. I would like to take this opportunity to thank all our developers for their effort over the last year. That effort has just culminated in PLplot-5.2.0 which is the best version yet! 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Robert S. <ro...@sc...> - 2003-01-21 06:38:50
|
On Mon, Jan 20, 2003 at 12:12:39AM -0800, Alan W. Irwin wrote: > To motivate you to try this new release, I should mention that the > python and java interfaces to PLplot are now much more complete > (thanks to swig). What's the state of the Perl/PDL interface? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Braunschweiger Str. 79, 31134 Hildesheim, Germany Handelsregister: Amtsgericht Hildesheim, HRA 2686 Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
From: Alan W. I. <ir...@be...> - 2003-01-21 18:24:51
|
On Mon, 20 Jan 2003, Robert Schwebel wrote: > On Mon, Jan 20, 2003 at 12:12:39AM -0800, Alan W. Irwin wrote: > > To motivate you to try this new release, I should mention that the > > python and java interfaces to PLplot are now much more complete > > (thanks to swig). > > What's the state of the Perl/PDL interface? I don't know about PDL since that is an independent effort (see Doug Hunt's messages to this list right after PLplot-5.1.0 was released last year). We do have a rudimentary perl interface as part of generic PLplot, but that is unsupported at this time because its developer ran out of time to work on it. Personally, I think we should abandon that approach (which depended on parsing the API from our DocBook API chapter) and go with swig instead. We already have two swig-generated interfaces (python and java) to PLplot which work very well. Using the python interface as an example, I was able to generate the java interface quite straightforwardly in about a week's worth of work in December with no prior swig experience and very little java experience. As a consequence of this swig exposure I have become a big convert. Swig currently can be used to generate interfaces for 9 different languages to C/C++ libraries. So I am hoping we can generate a lot of additional PLplot interfaces (including guile, scheme, ruby, and especially perl) with swig. Do we have a swig/perl interface volunteer? 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-01-21 20:15:12
|
* Alan W. Irwin <ir...@be...> [2003-01-21 10:23]: > On Mon, 20 Jan 2003, Robert Schwebel wrote: > > > What's the state of the Perl/PDL interface? > > I don't know about PDL since that is an independent effort (see Doug Hunt's > messages to this list right after PLplot-5.1.0 was released last year). Well, my original Perl bindings code had some limited support to PDL. However, I think that Doug's approach should be superior than mine. > We do have a rudimentary perl interface as part of generic PLplot, but that > is unsupported at this time because its developer ran out of time to work > on it. (That is me. I am still unable to participate to the PLplot effort. Too many things on the way.) > Personally, I think we should abandon that approach (which depended on > parsing the API from our DocBook API chapter) and go with swig instead. Well, my approach combined both parsing the XML source of the API _and_ usign swig (see bindings/perl5/README). I do not think that parsing the XML source is a bad idea, provided that the plplot.h is also automatically generated. It is unacceptable to have two sources of the same information being maintained in parallel. -- Rafael |
From: <jc...@fe...> - 2003-01-21 20:33:57
|
On Tuesday 21 January 2003 20:06, Rafael Laboissiere wrote: Hi Rafael! | * Alan W. Irwin <ir...@be...> [2003-01-21 10:23]: | > On Mon, 20 Jan 2003, Robert Schwebel wrote: | > > What's the state of the Perl/PDL interface? | > | > I don't know about PDL since that is an independent effort (see | > Doug Hunt's messages to this list right after PLplot-5.1.0 was | > released last year). | | Well, my original Perl bindings code had some limited support to PDL. | However, I think that Doug's approach should be superior than mine. | | > We do have a rudimentary perl interface as part of generic PLplot, | > but that is unsupported at this time because its developer ran out | > of time to work on it. | | (That is me. I am still unable to participate to the PLplot effort.=20 | Too many things on the way.) | | > Personally, I think we should abandon that approach (which depended | > on parsing the API from our DocBook API chapter) and go with swig | > instead. | | Well, my approach combined both parsing the XML source of the API | _and_ usign swig (see bindings/perl5/README). I do not think that | parsing the XML source is a bad idea, provided that the plplot.h is | also automatically generated. It is unacceptable to have two sources | of the same information being maintained in parallel. In that case, let the documentation be generated from the code and not=20 the other way around! And it's easier to maintain plplot.h than=20 api.xml. (apart from the fact that I still can't generate the docs!) Joao |
From: Alan W. I. <ir...@be...> - 2003-01-21 21:55:37
|
I will try to comment on what Joao and Rafael have said. On Tue, 21 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > On Tuesday 21 January 2003 20:06, Rafael Laboissiere wrote: > > Hi Rafael! > > | * Alan W. Irwin <ir...@be...> [2003-01-21 10:23]: > | > On Mon, 20 Jan 2003, Robert Schwebel wrote: > | > > What's the state of the Perl/PDL interface? > | > > | > I don't know about PDL since that is an independent effort (see > | > Doug Hunt's messages to this list right after PLplot-5.1.0 was > | > released last year). > | > | Well, my original Perl bindings code had some limited support to PDL. > | However, I think that Doug's approach should be superior than mine. > | > | > We do have a rudimentary perl interface as part of generic PLplot, > | > but that is unsupported at this time because its developer ran out > | > of time to work on it. > | > | (That is me. I am still unable to participate to the PLplot effort. > | Too many things on the way.) > | > | > Personally, I think we should abandon that approach (which depended > | > on parsing the API from our DocBook API chapter) and go with swig > | > instead. > | > | Well, my approach combined both parsing the XML source of the API > | _and_ usign swig (see bindings/perl5/README). OOPS. Sorry I missed that, Rafael. That immediately gives me much more interest in the current perl interface. > | I do not think that > | parsing the XML source is a bad idea, provided that the plplot.h is > | also automatically generated. It is unacceptable to have two sources > | of the same information being maintained in parallel. Rafael, I agree that one source for our API would be better, but it will take some effort, and we have lived with *many* parallel versions of our AP= I descriptions for a long time. So it is the old tradeoff between a constant= , maintenance problem that makes a steady drain on our time/effort, or doing something much better which requires a lot more immediate time/effort but pays off later in reducing the maintenance required. "Short term pain for long-term gain". Here is a summary of the current parallel API descriptions. We have the docbook chapter describing the API, plplot.h, two separate files describing the API for both java and python, and files describing the API for fortran and tcl as well. For the java and python case, the two files are almost identical, but they *must* differ slightly because the current java interface has cruder support of the call-back functions. Once that is sorted out, the two files could be merged together, but not yet. Also, these two files differ quite a bit from plplot.h to signal the swig typedef= s when something special has to be done with arguments (such as dropping redundant dimensions from argument lists). > > In that case, let the documentation be generated from the code and not > the other way around! And it's easier to maintain plplot.h than > api.xml. Joao, that's because api.xml has extra information such as detailed documentation of each argument far beyond the argument types and minimal documentation that plplot.h has at the moment. Therefore, since doc/docbook/src/api.xml has the most documentation information (by far) in an easily parsable form , I agree with Rafael that this file should be the ultimate source of all other descriptions of our API. To implement that, scripts need to be developed to generate include/plplot.h, bindings/python/plplotcapi, bindings/java/plplotcapi, bindings/tcl/plapi.tpl, and the equivalent API description file(s) for fortran. I have put such scripts in the rough order from highest to lowest priority. From Rafael's comments above , it also looks like a script has already been written to generate the required swig interface file for perl, but I imagine there is some more work to do on that as well. Rafael, generating include/plplot.h from doc/docbook/src/api.xml might be the type of small project that might interest you. How about it? 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-01-22 00:12:15
|
On Tuesday 21 January 2003 21:54, Alan W. Irwin wrote: > I will try to comment on what Joao and Rafael have said. > > On Tue, 21 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > > On Tuesday 21 January 2003 20:06, Rafael Laboissiere wrote: > > > > Hi Rafael! > > > > | * Alan W. Irwin <ir...@be...> [2003-01-21 10:23]: > > | > On Mon, 20 Jan 2003, Robert Schwebel wrote: > > | > > What's the state of the Perl/PDL interface? > > | > > > | > I don't know about PDL since that is an independent effort (see > > | > Doug Hunt's messages to this list right after PLplot-5.1.0 was > > | > released last year). > > | > > | Well, my original Perl bindings code had some limited support to PD= L. > > | However, I think that Doug's approach should be superior than mine. > > | > > | > We do have a rudimentary perl interface as part of generic PLplot= , > > | > but that is unsupported at this time because its developer ran ou= t > > | > of time to work on it. > > | > > | (That is me. I am still unable to participate to the PLplot effort= =2E > > | Too many things on the way.) > > | > > | > Personally, I think we should abandon that approach (which depend= ed > > | > on parsing the API from our DocBook API chapter) and go with swig > > | > instead. > > | > > | Well, my approach combined both parsing the XML source of the API > > | _and_ usign swig (see bindings/perl5/README). > > OOPS. Sorry I missed that, Rafael. That immediately gives me much mor= e > interest in the current perl interface. > > > | I do not think that > > | parsing the XML source is a bad idea, provided that the plplot.h is > > | also automatically generated. It is unacceptable to have two sourc= es > > | of the same information being maintained in parallel. > > Rafael, I agree that one source for our API would be better, but it wil= l > take some effort, and we have lived with *many* parallel versions of ou= r > API descriptions for a long time. So it is the old tradeoff between a > constant, maintenance problem that makes a steady drain on our time/eff= ort, > or doing something much better which requires a lot more immediate > time/effort but pays off later in reducing the maintenance required.=20 > "Short term pain for long-term gain". > > Here is a summary of the current parallel API descriptions. We have the > docbook chapter describing the API, plplot.h, two separate files descri= bing > the API for both java and python, and files describing the API for fort= ran > and tcl as well. For the java and python case, the two files are almos= t > identical, but they *must* differ slightly because the current java > interface has cruder support of the call-back functions. Once that is > sorted out, the two files could be merged together, but not yet. Also, > these two files differ quite a bit from plplot.h to signal the swig > typedefs when something special has to be done with arguments (such as > dropping redundant dimensions from argument lists). > > > In that case, let the documentation be generated from the code and no= t > > the other way around! And it's easier to maintain plplot.h than > > api.xml. > > Joao, that's because api.xml has extra information such as detailed > documentation of each argument far beyond the argument types and minima= l > documentation that plplot.h has at the moment. > > Therefore, since doc/docbook/src/api.xml has the most documentation > information (by far) in an easily parsable form , I agree with Rafael t= hat > this file should be the ultimate source of all other descriptions of ou= r > API. To implement that, scripts need to be developed to generate > include/plplot.h, bindings/python/plplotcapi, bindings/java/plplotcapi, > bindings/tcl/plapi.tpl, and the equivalent API description file(s) for > fortran. I have put such scripts in the rough order from highest to lo= west > priority. From Rafael's comments above , it also looks like a script h= as > already been written to generate the required swig interface file for p= erl, > but I imagine there is some more work to do on that as well. > > Rafael, generating include/plplot.h from doc/docbook/src/api.xml might = be > the type of small project that might interest you. How about it? That means that when I need to add/change something in plplot.h, because = I'm=20 *developing*, then I need to change api.xml, run the plplot.h building=20 scripts, make, eventually make install, and then restart from the beginin= g=20 several times. Is this the development model we want for plplot? I will b= e=20 out. Joao > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astron= omy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the Canadian Centre for Climate Modelling= and > Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting > software package (plplot.org). > > __________________________ > > Linux-powered Science > __________________________ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Alan W. I. <ir...@be...> - 2003-01-22 05:05:35
|
On Wed, 22 Jan 2003, Joao Cardoso wrote: > That means that when I need to add/change something in plplot.h, because I'm > *developing*, then I need to change api.xml..... Joao, you do have *one* legitimate point there which I will now discuss. Putting in all the xml boilerplate in api.xml does take quite an effort if done by hand. So here is the compromise that I propose instead. It means continued parallel development of api.xml and plplot.h, but good scripts can substantially reduce the maintenance cost of this parallel development. First, the script to convert from api.xml to plplot.h should include all the function and argument documentation in the generated plplot.h in a standard form. This would help guide developers in any future changes to plplot.h if they wanted to fully document their new API. Also, when any documenter runs that script they can carefully check that the resulting plplot.h is consistent with the original (except possibly for improvements in the documentation and whitespace changes). Second, a script should be developed (Rafael had something like this in rudimentary form years ago) to translate a single API description from plplot.h in standard form (i.e, including full documentation) to api.xml. If the developer has chosen not to put in documentation in plplot.h in the standard form, then some provision should be made to put in the phrase "NEEDS DOCUMENTATION" in the resulting api.xml fragment. With such a script, then any developer change to plplot.h can quickly be put into api.xml with a simple cut and paste operation. Here is how I think it would work in practice. After a developer has iterated on a change to plplot.h and finalized it, then he (or somebody else if the developer does not want to document his API) has the option to run the second script on the changed fragment and do the cut and paste to api.xml. Then follow with the first script to confirm plplot.h is consistent with api.xml. Of course all this discussion is moot without the two scripts. Rafael if you could make those two scripts, then they would be a big help to me in my forthcoming efforts to bring api.xml into consistency with plplot.h. Part of the reason why I have fallen behind in keeping api.xml up to date is I don't have such scripts. Also, if such easy-to-use scripts were available, I believe developers would be much more willing to document their API changes which would take additional documentation load off me. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-01-22 18:38:39
|
* Alan W. Irwin <ir...@be...> [2003-01-21 21:04]: > First, the script to convert from api.xml to plplot.h should include all > the function and argument documentation in the generated plplot.h in a > standard form. This would help guide developers in any future changes to > plplot.h if they wanted to fully document their new API. Also, when any > documenter runs that script they can carefully check that the resulting > plplot.h is consistent with the original (except possibly for improvements > in the documentation and whitespace changes). That script should not be too complicate to write. I already had something working for the perl5 bindings: bindings/perl5/api2bind.pl > Second, a script should be developed (Rafael had something like this in > rudimentary form years ago) to translate a single API description from > plplot.h in standard form (i.e, including full documentation) to api.xml. > If the developer has chosen not to put in documentation in plplot.h in the > standard form, then some provision should be made to put in the phrase > "NEEDS DOCUMENTATION" in the resulting api.xml fragment. With such a > script, then any developer change to plplot.h can quickly be put into > api.xml with a simple cut and paste operation. As far as I can remember, I never wrote any script to convert plplot.h into XML. That should not be too difficult to write, although one has to write a parser for C code... > Of course all this discussion is moot without the two scripts. > > Rafael if you could make those two scripts, [...] That an insteresting project, but I cannot commit myself to do it in the forseeable future. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-21 22:01:24
|
On Tue, 21 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > I still can't generate the docs! We have always been able to generate documentation using Debian. In RedHat 6.2 days it was difficult to generate the documentation on that system, but Maurice still managed to do it. I think docbook support is now much better for modern distributions of RedHat (and SuSe?), but I just haven't had time to try it. Joao, if you feel this is urgent, why don't you give it a try on your system now to see how far you can get following the directions in doc/docbook/README.developers? You might be surprised how easy it is. I do intend to look at this issue for RH7.3 within the next month or so, bu= t I would be quite happy if someone else beats me to it for that distribution= =2E After I or somebody else are successful with RH7.3, we can help Joao with any of his problems with building the documentation on SuSe (if such problems still exist). 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar= e package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-01-22 00:16:07
|
On Tuesday 21 January 2003 22:00, Alan W. Irwin wrote: > On Tue, 21 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > > I still can't generate the docs! > > We have always been able to generate documentation using Debian. In Red= Hat > 6.2 days it was difficult to generate the documentation on that system,= but > Maurice still managed to do it. I think docbook support is now much be= tter > for modern distributions of RedHat (and SuSe?), but I just haven't had = time > to try it. Joao, if you feel this is urgent, why don't you give it a tr= y on > your system now to see how far you can get following the directions in > doc/docbook/README.developers? You might be surprised how easy it is. I did try it several times. Not very engaged, but I tried. Following the=20 instructions doesn't work. Joao > > I do intend to look at this issue for RH7.3 within the next month or so= , > but I would be quite happy if someone else beats me to it for that > distribution. After I or somebody else are successful with RH7.3, we ca= n > help Joao with any of his problems with building the documentation on S= uSe > (if such problems still exist). > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astron= omy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the Canadian Centre for Climate Modelling= and > Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting > software package (plplot.org). > > __________________________ > > Linux-powered Science > __________________________ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Rafael L. <lab...@ps...> - 2003-01-22 18:28:22
|
* Alan W. Irwin <ir...@be...> [2003-01-21 14:00]: > On Tue, 21 Jan 2003, [iso-8859-1] João Cardoso wrote: > > > I still can't generate the docs! > > We have always been able to generate documentation using Debian. In RedHat > 6.2 days it was difficult to generate the documentation on that system, but > Maurice still managed to do it. I think docbook support is now much better > for modern distributions of RedHat (and SuSe?), but I just haven't had time > to try it. Joao, if you feel this is urgent, why don't you give it a try on > your system now to see how far you can get following the directions in > doc/docbook/README.developers? You might be surprised how easy it is. I am sure thigs will improve in the future, as DocBook (and XML) matures and becomes more standardized. Hopefully, when we will migrate from the present DSSSL scheme to a more modern XSLT one, things will be even better. -- Rafael |
From: Joao C. <jc...@fe...> - 2003-01-22 19:52:12
Attachments:
docs-build
|
On Tuesday 21 January 2003 22:00, Alan W. Irwin wrote: > On Tue, 21 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > > I still can't generate the docs! > > We have always been able to generate documentation using Debian. In Red= Hat > 6.2 days it was difficult to generate the documentation on that system,= but > Maurice still managed to do it. I think docbook support is now much be= tter > for modern distributions of RedHat (and SuSe?), but I just haven't had = time > to try it. Joao, if you feel this is urgent, why don't you give it a tr= y on > your system now to see how far you can get following the directions in > doc/docbook/README.developers? You might be surprised how easy it is. > > I do intend to look at this issue for RH7.3 within the next month or so= , > but I would be quite happy if someone else beats me to it for that > distribution. After I or somebody else are successful with RH7.3, we ca= n > help Joao with any of his problems with building the documentation on S= uSe > (if such problems still exist). I enclose a step-by-step log of my last attempt. Basicaly I can't run=20 bootstrap.sh, i.e., the autoconf step fails: > ./bootstrap.sh=20 =09configure.in:219: error: popdef: undefined macro: HTML =09configure.in:217: FILE_EXT is expanded from... =09configure.in:219: the top level > aclocal > automake --add-missing --gnu Makefile src/Makefile bin/Makefile > autoconf =09configure.in:219: error: popdef: undefined macro: HTML =09configure.in:217: FILE_EXT is expanded from... =09configure.in:219: the top level Clearly my autotools versions are capable of running plplot's top level=20 bootstrap.sh Joao > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astron= omy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the Canadian Centre for Climate Modelling= and > Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting > software package (plplot.org). > > __________________________ > > Linux-powered Science > __________________________ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Alan W. I. <ir...@be...> - 2003-01-22 23:48:04
|
On Wed, 22 Jan 2003, Joao Cardoso wrote: > I enclose a step-by-step log of my last attempt. Basicaly I can't run > bootstrap.sh, i.e., the autoconf step fails: > > > ./bootstrap.sh > configure.in:219: error: popdef: undefined macro: HTML > configure.in:217: FILE_EXT is expanded from... > configure.in:219: the top level > > > aclocal > > automake --add-missing --gnu Makefile src/Makefile bin/Makefile > > autoconf > configure.in:219: error: popdef: undefined macro: HTML > configure.in:217: FILE_EXT is expanded from... > configure.in:219: the top level > > Clearly my autotools versions are capable of running plplot's top level > bootstrap.sh. Thanks for this report, Joao. Recall, I built the documentation with the mixed autotools version from Debian and uploaded it to SF, and only switched to the pure latest versions of autotools for the final tarball release (which does not build the documentation, instead it just downloads it from SF). Thus, the peculiar release process for PLplot-5.2.0 did not actually test whether the pure latest autotools will generate the documentation from the DocBook-XML source. Therefore, in light of your report I just tried that test, and I confirm the error you have found. I will put fixing this autotools version issue on my ToDo list for the next time I update the documentation. I should emphasize for the PLplot users on this list, that this issue does not affect ordinary users who can just download or view the generated documentation (html, postscript, dvi, pdf, info, and man forms) from http://plplot.sourceforge.net/resources/docbook-manual/. 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 Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |