From: <jc...@fe...> - 2003-01-24 15:24:04
|
Hi, Make plplot-5.2.0 fails on a freshly installed Red-Hat-8.0. configure runs OK, make also runs OK in the src directory but when it=20 reaches the include directory it fails, see the messages bellow. Red-Hat-8.0 has autoconf-2.53, even after an online update. Also octave was left disabled by default. Joao [jcard@clio plplot-5.2.0]$ more config.summary=20 Configure results: command: ./configure --disable-static --prefix /home/jcard=20 --enable-dyndrivers --enable-octave system: i686-pc-linux-gnu prefix: /home/jcard CC: gcc=20 CXX: g++=20 F77: g77=20 LIB_TAG: devices: dg300 png jpeg hp7470 hp7580 lj_hpgl imp ljii ljiip=20 null pbm pl meta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt conex=20 tek4010f te k4107f tk xfig xwin Available device drivers static: dynamic: dg300_drv.la gd_drv.la hpgl_drv.la impress_drv.la=20 ljii_drv.la l jiip_drv.la null_drv.la pbm_drv.la plmeta_drv.la ps_drv.la pstex_drv.la=20 tek_drv. la tk_drv.la xfig_drv.la xwin_drv.la with_shlib: yes with_double: no with_debug: no with_opt: yes with_warn: no with_profile: no with_gcc: yes with_rpath: yes with_freetype: no enable_xwin: yes enable_tcl: yes enable_tk: yes enable_itcl: no enable_cxx: yes enable_python: no enable_f77: yes enable_java: no enable_octave: yes enable_gnome: no enable_tkwin: no [jcard@clio plplot-5.2.0]$ make Making all in libltdl make[1]: Entering directory `/home/jcard/plplot-5.2.0/libltdl' make[1]: Leaving directory `/home/jcard/plplot-5.2.0/libltdl' Making all in src make[1]: Entering directory `/home/jcard/plplot-5.2.0/src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/jcard/plplot-5.2.0/src' Making all in include make[1]: Entering directory `/home/jcard/plplot-5.2.0/include' cd .. && /bin/sh /home/jcard/plplot-5.2.0/missing --run autoheader WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. aclocal.m4:889: error: Autoconf version 2.54 or higher is required aclocal.m4:889: the top level autoheader: autom4te-2.53 failed with exit status: 1 at /usr/bin/autoheader line 163 make[1]: *** [plDevs.h.in] Error 1 make[1]: Leaving directory `/home/jcard/plplot-5.2.0/include' make: *** [all-recursive] Error 1 [jcard@clio plplot-5.2.0]$ autoconf --version autoconf (GNU Autoconf) 2.53 [jcard@clio plplot-5.2.0]$ more /etc/issue Red Hat Linux release 8.0 (Psyche) Kernel \r on an \m |
From: <jc...@fe...> - 2003-01-24 18:24:25
|
On Friday 24 January 2003 15:25, Jo=E3o Cardoso wrote: | Hi, | | Make plplot-5.2.0 fails on a freshly installed Red-Hat-8.0. | | configure runs OK, make also runs OK in the src directory but when it | reaches the include directory it fails, see the messages bellow. | Red-Hat-8.0 has autoconf-2.53, even after an online update. The same happens on a alpha OSF1 machine, but now it is autoheader that=20 is missing. It looks like the include directory has problems. Look=20 bellow. I tried again, disabling octave, and it now runs OK. Also, the xwin driver, that I have reported not to work previously, is=20 now working. The c, cxx and f77 examples with the xwin driver also=20 work, so it looks like the problem is octave. I will check again in the=20 Red-Hat machine with octave disabled. The configure command that worked om the OSF machine: =2E/configure --disable-static --prefix=3D/usr/users1/deec/jcard/tes t --enable-dyndrivers I forgot to say that I'm using the plplot-5.2.0.tar.gz available at our=20 site. Joao -------------------------------------------------------------------------= --------------------------------- Making all in include make[1]: Entering directory=20 `/usr/users1/deec/jcard/plplot-5.2.0/include' cd .. && /bin/bash /usr/users1/deec/jcard/plplot-5.2.0/missing --run=20 autoheader /usr/users1/deec/jcard/plplot-5.2.0/missing: autoheader: command not=20 found WARNING: `autoheader' is missing on your system. You should only need=20 it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. touch ./plDevs.h.in cd .. && /bin/bash ./config.status include/plDevs.h make[1]: *** [stamp-h2] Error 139 make[1]: Leaving directory `/usr/users1/deec/jcard/plplot-5.2.0/include' make: *** [all-recursive] Error 1 bash-2.01$=20 Joao |
From: <jc...@fe...> - 2003-01-24 18:52:02
|
On Friday 24 January 2003 18:25, Jo=E3o Cardoso wrote: | On Friday 24 January 2003 15:25, Jo=E3o Cardoso wrote: | | Hi, | | | | Make plplot-5.2.0 fails on a freshly installed Red-Hat-8.0. | | | | configure runs OK, make also runs OK in the src directory but when | | it reaches the include directory it fails, see the messages bellow. | | Red-Hat-8.0 has autoconf-2.53, even after an online update. | | The same happens on a alpha OSF1 machine, but now it is autoheader | that is missing. It looks like the include directory has problems. | Look bellow. | | I tried again, disabling octave, and it now runs OK. | Also, the xwin driver, that I have reported not to work previously, | is now working. The c, cxx and f77 examples with the xwin driver also | work, so it looks like the problem is octave. I will check again in | the Red-Hat machine with octave disabled. Nope, it still gives the same error, described in my first e-mail. Even if configured with a plain: =2E/configure --prefix /home/jcard --enable-dyndrivers For completeness, I tried the same in Suse-8.1, and the problem is=20 exactly the same as in the Red-Hat-8.0. I used several configure=20 options, even a plain ./configure, all with the same result. Joao | The configure command that worked om the OSF machine: | ./configure --disable-static --prefix=3D/usr/users1/deec/jcard/tes | t --enable-dyndrivers | | I forgot to say that I'm using the plplot-5.2.0.tar.gz available at | our site. | | Joao | | --------------------------------------------------------------------- |------------------------------------- Making all in include | make[1]: Entering directory | `/usr/users1/deec/jcard/plplot-5.2.0/include' | cd .. && /bin/bash /usr/users1/deec/jcard/plplot-5.2.0/missing --run | autoheader | /usr/users1/deec/jcard/plplot-5.2.0/missing: autoheader: command not | found | WARNING: `autoheader' is missing on your system. You should only | need it if | you modified `acconfig.h' or `configure.ac'. You might want | to install the `Autoconf' and `GNU m4' packages. Grab them | from any GNU archive site. | touch ./plDevs.h.in | cd .. && /bin/bash ./config.status include/plDevs.h | make[1]: *** [stamp-h2] Error 139 | make[1]: Leaving directory | `/usr/users1/deec/jcard/plplot-5.2.0/include' make: *** | [all-recursive] Error 1 | bash-2.01$ | | Joao | | | ------------------------------------------------------- | This SF.NET email is sponsored by: | SourceForge Enterprise Edition + IBM + LinuxWorld | http://www.vasoftware.com | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2003-01-24 19:16:58
|
On Fri, 24 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > Nope, it still gives the same error, described in my first e-mail. > Even if configured with a plain: > ./configure --prefix /home/jcard --enable-dyndrivers > > For completeness, I tried the same in Suse-8.1, and the problem is > exactly the same as in the Red-Hat-8.0. I used several configure > options, even a plain ./configure, all with the same result. So therefore this is a general problem with the PLplot-5.2.0 tarball not limited to just octave. UGH. To add information, please also check your CVS build with your own autotools. Is 'missing --run autoheader' invoked after ./bootstrap.sh in that case as well? Of course it will work in that case since your autotool= s will be self-consistent, but I don't think missing should be invoked at all= =2E Maurice, will you please take over as the leader of this debugging effort? I just don't have the autoconf background that you do, and this weekend is already solidly booked by my job to make up for the time I have already spent on the PLplot release. Also, Maurice, if you confirm the problem, I will send out a notice on PLplot general that we have found a problem with the tarball that makes it not build on a number of platforms, and we are working to resolve the problem. 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: <jc...@fe...> - 2003-01-24 20:10:46
|
On Friday 24 January 2003 19:15, Alan W. Irwin wrote: | On Fri, 24 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: | > Nope, it still gives the same error, described in my first e-mail. | > Even if configured with a plain: | > ./configure --prefix /home/jcard --enable-dyndrivers | > | > For completeness, I tried the same in Suse-8.1, and the problem is | > exactly the same as in the Red-Hat-8.0. I used several configure | > options, even a plain ./configure, all with the same result. | | So therefore this is a general problem with the PLplot-5.2.0 | tarball not limited to just octave. UGH. | | To add information, please also check your CVS build with your own | autotools. Is 'missing --run autoheader' invoked after | ./bootstrap.sh in that case as well? Not exactly. 'configure' runs OK in all platforms, and 'make' also=20 compiles many sources. It's only when 'make' finish building the plplot=20 library that it cd to the include directory and fails. (Notice, at the=20 end of this mail there is a clue to solve the problem) With my cvs tree the same happens: (...) meta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt conex=20 tek4010f te(cd .libs && rm -f libplplot.la && ln -s ../libplplot.la=20 libplplot.la) make[1]: Leaving directory `/home/jcard/plplot/src' Making all in include make[1]: Entering directory `/home/jcard/plplot/include' cd .. && /bin/sh /home/jcard/plplot/missing --run autoheader WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `include/plConfig.h.in' is unchanged touch ./plDevs.h.in cd .. && /bin/sh ./config.status include/plDevs.h config.status: creating include/plDevs.h config.status: include/plDevs.h is unchanged make all-am make[2]: Entering directory `/home/jcard/plplot/include' make[2]: Leaving directory `/home/jcard/plplot/include' make[1]: Leaving directory `/home/jcard/plplot/include' Making all in lib (...) Meanwhile, I tried it again in the OSF machine, removing the plplot=20 directory, unpacking, configuring and make, and it failed again, so it=20 seems that subsequent configure/make "solves" the problem? Odd. uhmm, under OSF the problem is another one, its '/bin/bash=20 =2E/config.status include/plDevs.h' that fails: WARNING: `autoheader' is missing on your system. You should only need=20 it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. touch ./plDevs.h.in cd .. && /bin/bash ./config.status include/plDevs.h make[1]: *** [stamp-h2] Error 139 make[1]: Leaving directory `/usr/users1/deec/jcard/plplot-5.2.0/include' make: *** [all-recursive] Error 1 bash-2.01$ /bin/bash ./config.status include/plDevs.h Segmentation fault <------------------------------------------------- bash-2.01$ /bin/sh ./config.status include/plDevs.h config.status: creating include/plDevs.h config.status: include/plDevs.h is unchanged And now a 'make -i' goes through the end, then make -i install, make -i=20 check, etc run OK. So, lets forget the OSF machine where *another* problem is breaking the=20 make. But it gives clues to solve the other systems problem. In OSF, as=20 autotools does not exists, the make continues after the warning (but=20 stops afterwards because of the *other*, not plplot related problem). In the platforms that have autotools, the problem arises because of a=20 version conflict. Just that. Joao | Of course it will work in that | case since your autotools will be self-consistent, but I don't think | missing should be invoked at all. | | Maurice, will you please take over as the leader of this debugging | effort? I just don't have the autoconf background that you do, and | this weekend is already solidly booked by my job to make up for the | time I have already spent on the PLplot release. | | Also, Maurice, if you confirm the problem, I will send out a notice | on PLplot general that we have found a problem with the tarball that | makes it not build on a number of platforms, and we are working to | resolve the problem. | | 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: Alan W. I. <ir...@be...> - 2003-01-24 19:00:51
|
On Fri, 24 Jan 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > > Hi, > > Make plplot-5.2.0 fails on a freshly installed Red-Hat-8.0. > [...] > Making all in include > make[1]: Entering directory `/home/jcard/plplot-5.2.0/include' > cd .. && /bin/sh /home/jcard/plplot-5.2.0/missing --run autoheader > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > WARNING: and `config.h.top', to define templates for `config.h.in' > WARNING: is deprecated and discouraged. > > WARNING: Using the third argument of `AC_DEFINE' and > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > WARNING: `acconfig.h': > > WARNING: AC_DEFINE([NEED_MAIN], 1, > WARNING: [Define if a function `main' is needed.]) > > WARNING: More sophisticated templates can also be produced, see the > WARNING: documentation. > aclocal.m4:889: error: Autoconf version 2.54 or higher is required > aclocal.m4:889: the top level > autoheader: autom4te-2.53 failed with exit status: 1 > at /usr/bin/autoheader line 163 > make[1]: *** [plDevs.h.in] Error 1 > make[1]: Leaving directory `/home/jcard/plplot-5.2.0/include' > make: *** [all-recursive] Error 1 I also read Joao's later message where he reported similar errors for other platforms using the plplot-5.2.0 tarball. Interestingly, the problem seems to go away without octave. This one has me frankly stumped. On the RH 7.3 system that is accessible t= o me, I get the following results in the same place (with octave enabled). make[1]: Entering directory /nfs/orc0/home/irwin/software/rpm_build/BUILD/plplo t-5.2.0/include' cd .. && /bin/sh /nfs/orc0/home/irwin/software/rpm_build/BUILD/plplot-5.2.0/missing --run au= toheader /usr/bin/m4: configure.in: No such file or directory touch ./plDevs.h.in The whole point of autotools is if you run ./bootstrap.sh before hand (as was done for the tarball which you are using, and I am using on RH7.3) then no autotools should be required by the user of that tarball. 'missing --ru= n autoheader' is *not* run on my Debian system after ./bootstrap.sh. Yet, both on RH 7.3 and RH 8.0 'missing --run autoheader' is invoked, and as far as I know it shouldn't be. In the RH7.3 case, it doesn't matter (I think by luck rather than design) because it bails out when configure.in is not there and then the whole process goes on to success, but that is obviously not the case for RH 8.0. Maurice, after you run ./bootstrap.sh on all machines accessible to you (or if you are using the 5.2.0 tarball where ./bootstrap.sh has already been executed) is 'missing --run autoheader' invoked later by the make? Personally, I think we are the victim of an autoconf bug in the severely deprecated parts of autoconf that we are using, and I would like to see us move away from that deprecated use as soon as possible. Maurice, would you be willing to give that a try to see if it solves this serious problem? Since this problem (invoking 'missing --run autoheader' after =2E/bootstrap.sh) is potentially quite serious, I am going to hold off on a= ny further publicity about PLplot-5.2.0 until we better understand the problem and find a solution. If there is no simple workaround, and we have to make file changes, then I am quite willing to bring out PLplot-5.2.1 in a hurry once we have the definitive fix. 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: Rafael L. <lab...@ps...> - 2003-01-26 22:20:12
|
As you know all, I do not have time right now to work on PLplot. Although, I use to skim over the messages in the mailing list from time to time. Joao's report below called my attention, because a non-compilable tarball is a very serious problem and I find the bug report quite intriguing. * João Cardoso <jc...@fe...> [2003-01-24 15:25]: > [explanation of problem deleted] > > [jcard@clio plplot-5.2.0]$ make > [some make messages deleted] > Making all in include > make[1]: Entering directory `/home/jcard/plplot-5.2.0/include' > cd .. && /bin/sh /home/jcard/plplot-5.2.0/missing --run autoheader This call to autoheader (through the `missing' script) should never, never, I repeat: _NEVER_ happen when regular users run make. None of the Autotools should be called during a normal make, since this would defeat the very purpose of the Autotools. The only tools that are required for configure/make are a Bourne shell and a regular make (not even GNU make). Automake, for instance, should only be called from the Makefile when developpers change one of the autotools source files (like aclocal.m4, configure.ac, etc). Something is really weird with the 5.2.0 distribution tarball. As I told before, I do not have time to plunge into this problem, but here is a first try on its diagnosis: When I run ./configure here on a freshly detarized 5.2.0 distribution, I get the following rules in include/Makefile: $(srcdir)/plConfig.h.in: $(top_srcdir)/configure.ac $(ACLOCAL_M4) $(top_srcdir) /acconfig.h cd $(top_srcdir) && $(AUTOHEADER) touch $(srcdir)/plConfig.h.in $(srcdir)/plDevs.h.in: $(top_srcdir)/configure.ac $(ACLOCAL_M4) $(top_srcdir)/a cconfig.h cd $(top_srcdir) && $(AUTOHEADER) touch $(srcdir)/plDevs.h.in This is a complete non-sense, since there are no src/plConfig.h.in and src/plDevs.h.in to be built! This is what is triggering the call to autoheader from make, which should never, I repeat, never occurs for regular users. I have no clue about where the source of the problem is. It is possibly related to the assumptions that the macro AM_CONFIG_HEADERS makes about the location of *.h.in files. Of course, I am wildly guessing here. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-27 00:24:58
|
On Sun, 26 Jan 2003, Rafael Laboissiere wrote: > This call to autoheader (through the `missing' script) should never, never, > I repeat: _NEVER_ happen when regular users run make. None of the Autotools > should be called during a normal make, since this would defeat the very > purpose of the Autotools. The only tools that are required for > configure/make are a Bourne shell and a regular make (not even GNU make). I agree; that is the whole design philosophy behind autotools. > > Automake, for instance, should only be called from the Makefile when > developpers change one of the autotools source files (like aclocal.m4, > configure.ac, etc). Something is really weird with the 5.2.0 distribution > tarball. > > As I told before, I do not have time to plunge into this problem, but here > is a first try on its diagnosis: Thanks, Rafael, for starting the ball rolling here. You inspired me to find what I think is the correct solution (see end). > > When I run ./configure here on a freshly detarized 5.2.0 distribution, I get > the following rules in include/Makefile: > > $(srcdir)/plConfig.h.in: $(top_srcdir)/configure.ac $(ACLOCAL_M4) $(top_srcdir)/acconfig.h > cd $(top_srcdir) && $(AUTOHEADER) > touch $(srcdir)/plConfig.h.in > > $(srcdir)/plDevs.h.in: $(top_srcdir)/configure.ac $(ACLOCAL_M4) $(top_srcdir)/acconfig.h > cd $(top_srcdir) && $(AUTOHEADER) > touch $(srcdir)/plDevs.h.in > > This is a complete non-sense, since there are no src/plConfig.h.in and > src/plDevs.h.in to be built! This is what is triggering the call to > autoheader from make, which should never, I repeat, never occurs for regular > users. Actually, this makes sense. Remember, $(srcdir) is the current directory, i.e., include. So these two rules say run $(AUTOHEADER) if plConfig.h.in or plDevs.h.in in the include directory are out of date relative to $(ACLOCAL_M4) (defined to be $(top_srcdir)/aclocal.m4 in the top-level Makefile) and configure.ac or acconfig.h in the top level directory. So if bootstrap.sh (which invokes autoheader) updates plConfig.h.in and plDevs.h.in, then the above rules will only be run if the user fiddles with configure.ac, acconfig.h, or aclocal.m4 in the top-level directory. However, further investigation reveals bootstrap (and autoheader inside it) did not do its job: tar ztvf ../plplot-5.2.0.tar.gz | grep include |grep '\.in$' -rw-r--r-- software/software 4635 2003-01-19 22:00:30 plplot-5.2.0/include/plConfig.h.in -rw-r--r-- software/software 1056 2002-12-03 00:39:26 plplot-5.2.0/include/plDevs.h.in -rw-r--r-- software/software 15875 2003-01-19 22:00:27 plplot-5.2.0/include/Makefile.in plConfig.h.in and Makefile.in were properly updated, but plDevs.h.in has an old date! It turns out this December 3rd date is older than the relevant top-level files so the $(AUTOHEADER) rule is run (in error), and I believe this is the source of the trouble that Joao found. How to fix it? I think the problem here is that plDevs.h.in is under CVS control (as it should be) so a file exists already and this confuses autoheader. In fact autoheader should *never* be invoked on this file. Thus, I believe the complete solution is simply to do the following changes in configure.ac: AM_CONFIG_HEADER(include/plConfig.h include/plDevs.h) ==> AM_CONFIG_HEADER(include/plConfig.h) src/Makefile include/Makefile ==> src/Makefile include/Makefile include/plDevs.h i.e, Remove the generation of plDevs.h.in from autoheader control and put the generation of plDevs.h under autoconf control. Note on Joao's systems and on the RH 7.3 system available to me the complaints were always about plDevs.h.in, and nothing was said about plConfig.h.in which I think autoheader is handling without any problems (since that file is not under CVS control there is nothing in the exported tree from CVS there before ./bootstrap.sh creates it with autoheader). Maurice and Rafael, do you agree with this analysis? 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: Maurice L. <mj...@ga...> - 2003-01-27 05:01:43
|
Alan W. Irwin writes: > ... > Thanks, Rafael, for starting the ball rolling here. You inspired me to find > what I think is the correct solution (see end). BTW I have confirmed the problem on my RH 7.3 system using the tarball. When running make, I see: Making all in include cd .. && /bin/sh /home/mjl/dev/plplot/projects/plplot-5.2.0/missing --run autoheader > However, further investigation reveals bootstrap (and autoheader inside > it) did not do its job: > ... It now appears broken in a different way. The plDevs.h file that gets created by configure has no macros defined at all! The build actually failed b/c of an unresolved dependency that shouldn't have happened, but this is a secondary issue. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2003-01-27 06:42:26
|
On Sun, 26 Jan 2003, Maurice LeBrun wrote: > It now appears broken in a different way. The plDevs.h file that gets created > by configure has no macros defined at all! The build actually failed b/c of > an unresolved dependency that shouldn't have happened, but this is a secondary > issue. I also ran into this problem. With plDevs.h showing tk undefined, tcpip.lo is compiled with nothing in it, and this screws up the build for obvious reasons. I mentioned a quick workaround in my previous post, but the question is do you have the time/energy for doing the fundamental fix --- changing configure.ac or its associated files so that plDevs.h is created properly or else dropping plDevs.h, altogether Alan > > -- > Maurice LeBrun mj...@ga... > Research Organization for Information Science and Technology of Japan (RIST) > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > __________________________ 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: Alan W. I. <ir...@be...> - 2003-01-27 06:36:41
|
On Sun, 26 Jan 2003, Alan W. Irwin wrote: > Thus, I believe the complete solution is simply to do the following changes > in configure.ac: > > AM_CONFIG_HEADER(include/plConfig.h include/plDevs.h) ==> > AM_CONFIG_HEADER(include/plConfig.h) > > src/Makefile > include/Makefile > > ==> > src/Makefile > include/Makefile > include/plDevs.h > > i.e, Remove the generation of plDevs.h.in from autoheader control and put > the generation of plDevs.h under autoconf control. > > Maurice and Rafael, do you agree with this analysis? Well, I tried the above change (see CVS HEAD where I committed the change for discussion purposes), but it didn't work, and I think Maurice has just run into the same problem. I assumed that all you had to do above was mention plDevs.h, in AC_OUTPUT, and autoconf would take care of the rest, but all it did was simply copy plDevs.h.in to plDevs.h, which of course isn't what we want. I believe a quick workaround for the original date problem that causes this mess is to revert back configure.ac to what we had before and simply touch include/plDevs.h.in right before bootstrap.sh is invoked and the tarball created. But I would much prefer this problem to be solved at a fundamental level rather than with such a workaround which is bound to come back and haunt us. One question that springs to mind is why do we have all the device #define's both in plConfig.h and PlDevs.h? Could we just drop plDevs.h altogether (at least for Linux/Unix systems) and use only plConfig.h? That would require some big but straightforward changes to our hierarchy of PLplot includes, but I think it would work. Alternatively, if we really want PlDevs.h created separately, then somebody has to figure out the autoconf commands to process Pldevs.h.in into PlDevs.h properly without using the AM_CONFIG_HEADER macro (which would run you into the date problems which started this thread). 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-27 08:50:51
|
* Alan W. Irwin <ir...@be...> [2003-01-26 22:35]: > One question that springs to mind is why do we have all the device #define's > both in plConfig.h and PlDevs.h? Could we just drop plDevs.h altogether (at > least for Linux/Unix systems) and use only plConfig.h? That would require > some big but straightforward changes to our hierarchy of PLplot includes, > but I think it would work. > > Alternatively, if we really want PlDevs.h created separately, then somebody > has to figure out the autoconf commands to process Pldevs.h.in into PlDevs.h > properly without using the AM_CONFIG_HEADER macro (which would run you into > the date problems which started this thread). This is a very serious bug and I will try to find some time tonight to try to find a decent solution. I agree with Alan that this must be fixed properly. Workarounds today will only result on headaches tomorrow. I think that if/when this bug is fixed, a new 5.2.1 tarball will have to be released. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-27 18:23:45
|
On Mon, 27 Jan 2003, Rafael Laboissiere wrote: > This is a very serious bug and I will try to find some time tonight to try > to find a decent solution. I agree with Alan that this must be fixed > properly. Workarounds today will only result on headaches tomorrow. > > I think that if/when this bug is fixed, a new 5.2.1 tarball will have to be > released. I suggest using a dual-track short-term and long-term strategy for solving the problem. Short-term so that those who have already downloaded 5.2.0 can get something out of it, and long-term for a more fundamental solution. (1) Short-term (time scale of a day or so). Joao and Maurice, will you please try the suggested workaround to make sure it cures all the problems you found? With the current plplot-5.2.0 tarball simply unpack it and touch include/plDevs.h.in before running configure; make; make install. If I am right about this "touch" workaround, there should be absolutely no attempt to run autoheader (or any other autotool) at the make stage. I will do the same test here (this evening after work). If we all find no problems, then I will immediately publish that workaround to plplot-general (and in the SF release notes for 5.2.0) and also indicate we are working on plplot-5.2.1 which will solve the problem at a more fundamental level. (2) Longer term (time scale of a week or so). Find a fundamental solution. I believe this is absolutely necessary because from my further reading of the documentation of AM_CONFIG_HEADER and its autoconf counterpart AC_CONFIG_HEADER, it is amazing our use of two files in the argument list for AM_CONFIG_HEADER actually worked at all (albeit with the date problems for plDevs.h.in). There is still a lot of change going on with both automake and autoconf so I would be most surprised if our two-file solution worked in the slightest for future autoconf/autoheader versions. Rafael, you have much more autoconf expertise than I do, so I very much appreciate your offer to try and find a fundamental solution. Without your effort it might take a number of weekends for me to find a solution. Once such a fundamental solution is found (and I do hope Rafael is able to find such a solution tonight), I will adjust the version (the people maintaining all the windows versions in sys will have to follow with their own version number changes) soon after and bring out 5.2.1 on the next weekend (hopefully, this weekend if Rafael is immediately successful). 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: <jc...@fe...> - 2003-01-27 19:13:57
|
On Monday 27 January 2003 18:22, Alan W. Irwin wrote: | On Mon, 27 Jan 2003, Rafael Laboissiere wrote: | > This is a very serious bug and I will try to find some time tonight | > to try to find a decent solution. I agree with Alan that this must | > be fixed properly. Workarounds today will only result on headaches | > tomorrow. | > | > I think that if/when this bug is fixed, a new 5.2.1 tarball will | > have to be released. | | I suggest using a dual-track short-term and long-term strategy for | solving the problem. Short-term so that those who have already | downloaded 5.2.0 can get something out of it, and long-term for a | more fundamental solution. | | (1) Short-term (time scale of a day or so). Joao and Maurice, will | you please try the suggested workaround to make sure it cures all the | problems you found? With the current plplot-5.2.0 tarball simply | unpack it and touch include/plDevs.h.in before running configure; | make; make install. If I am right about this "touch" workaround, | there should be absolutely no attempt to run autoheader (or any other | autotool) at the make stage. You are right. On Red-Hat-8.0, SuSE-8.1 and on an OSF1 alpha machine, untaring,=20 configure --disable-static --enable-dyndrivers --prefix=3D<xxx>, make,=20 make install, cd <installdir>/lib/plplot5.2.0/c/examples, make x01c,=20 =2E/x01c run fine. No trace of the words "missing" or "auto" in the make or make install=20 logs of all three machines. Joao |
From: Maurice L. <mj...@ga...> - 2003-01-27 22:14:51
|
Alan W. Irwin writes: > On Mon, 27 Jan 2003, Rafael Laboissiere wrote: > > > This is a very serious bug and I will try to find some time tonight to try > > to find a decent solution. I agree with Alan that this must be fixed > > properly. Workarounds today will only result on headaches tomorrow. > > > > I think that if/when this bug is fixed, a new 5.2.1 tarball will have to be > > released. > > I suggest using a dual-track short-term and long-term strategy for solving > the problem. Short-term so that those who have already downloaded 5.2.0 > can get something out of it, and long-term for a more fundamental solution. > > (1) Short-term (time scale of a day or so). Joao and Maurice, will you > please try the suggested workaround to make sure it cures all the problems > you found? With the current plplot-5.2.0 tarball simply unpack it and touch > include/plDevs.h.in before running configure; make; make install. If I am > right about this "touch" workaround, there should be absolutely no attempt > to run autoheader (or any other autotool) at the make stage. I will do the > same test here (this evening after work). If we all find no problems, then > I will immediately publish that workaround to plplot-general (and in the SF > release notes for 5.2.0) and also indicate we are working on plplot-5.2.1 > which will solve the problem at a more fundamental level. I've verified this approach does work on my RH 7.3 system. > (2) Longer term (time scale of a week or so). Find a fundamental solution. I > believe this is absolutely necessary because from my further reading of the > documentation of AM_CONFIG_HEADER and its autoconf counterpart > AC_CONFIG_HEADER, it is amazing our use of two files in the argument list > for AM_CONFIG_HEADER actually worked at all (albeit with the date problems > for plDevs.h.in). There is still a lot of change going on with both > automake and autoconf so I would be most surprised if our two-file solution > worked in the slightest for future autoconf/autoheader versions. I'm not sure about AM_CONFIG_HEADER, but AC_CONFIG_HEADER definitely works given multiple args. Probably AM_CONFIG_HEADER does too since it's just a front-end to AC_CONFIG_HEADER. There's also now some *_CONFIG_HEADERS (note the trailing "S") but I don't know if these are the same or what. Man, what a mess. Anyhow, the current cvs HEAD configuration is now badly broken. Adding plDevs.h to AC_OUTPUT doesn't work -- headers have to be treated specially. So we should go back to the previous version of configure.ac until this is all sorted out. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2003-01-27 23:27:05
|
On Mon, 27 Jan 2003, Maurice LeBrun wrote: > Anyhow, the current cvs HEAD configuration is now badly broken. Adding > plDevs.h to AC_OUTPUT doesn't work -- headers have to be treated specially. Yup. Live and learn. I have just reverted back to the plplot-5.2.0 version. But a lot more has to be done along the lines of what Rafael suggested. 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-27 22:00:56
|
I have plunged more deeply into the header configuration problem. I seems that that are several small independent problems and the conjunction of some of them may have been triggering the bug observed by Joao. Let us see which are those problems: 1) AC_CONFIG_HEADERS should be used in place of AM_CONFIG_HEADER in configure.ac. I guess that the use of the deprecated AM_CONFIG_HEADER is harmful with the present version of autoconf/automake, but who nows. 2) The file include/plDevs.h is totally useless since all of its definitions are already duplicated in include/plConfig.h. I would recommend to delete taht file from the repository (or actually include/plDevs.h.in) and replace all inclusions of plDevs.h by plConfig.h. The files concerned by this change are drivers/*.c, bindings/tk/{plserver.h,tcpip.c}, include/plcore.h, and src/plfreetype.c. Also, remove include/plDevs.h from the call to AC_CONFIG_HEADERS in configure.ac and from the list pkginclude_HEADERS in include/Makefile.am. 3) Autoheader is being called in bootstrap.sh unnecessarily. Autoheader is only needed when there is no config.h.in source file (in our case include/plConfig.h.in), since it is created automatically from the AC_DEFINE macros seen in configure.ac. 4) There is a deprecated file acconfig.h from the top-level directory. We can happily remove it from the CVS repository. I have no time to do extensive tests, but implementing the suggestions above should fix the problem, or at least make a step forward in having a more sane headers configuration. Another unrelated bizarre thing is the command "touch include/plConfig.h.in" in bootstrap.sh. From the CVS log, this was introduced in the AM-LT branch, as a workround for problems that I found with autoheader (see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plplot/plplot/bootstrap.sh?rev=1.1.2.4&content-type=text/vnd.viewcvs-markup) If autoheader is not called any more in bootstrap.sh, I think that that touch command should be also removed. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-27 23:08:44
|
On Mon, 27 Jan 2003, Rafael Laboissiere wrote: > I have plunged more deeply into the header configuration problem. I seems > that that are several small independent problems and the conjunction of some > of them may have been triggering the bug observed by Joao. Let us see which > are those problems: > > 1) AC_CONFIG_HEADERS should be used in place of AM_CONFIG_HEADER in > configure.ac. I guess that the use of the deprecated AM_CONFIG_HEADER is > harmful with the present version of autoconf/automake, but who nows. Can you give a reference for the "deprecated". I have the impression you are correct, but when I looked for it last night I got two stories, (from info automake) AM_CONFIG_HEADER required and AM_CONFIG_HEADER optional. I am sure I have also seen the story "deprecated", but can you remind me where? > > 2) The file include/plDevs.h is totally useless since all of its definitions > are already duplicated in include/plConfig.h. I would recommend to > delete taht file from the repository (or actually include/plDevs.h.in) > and replace all inclusions of plDevs.h by plConfig.h. The files > concerned by this change are drivers/*.c, > bindings/tk/{plserver.h,tcpip.c}, include/plcore.h, and src/plfreetype.c. > Also, remove include/plDevs.h from the call to AC_CONFIG_HEADERS in > configure.ac and from the list pkginclude_HEADERS in include/Makefile.am. Agreed. That's a lot of work but straightforward. > > 3) Autoheader is being called in bootstrap.sh unnecessarily. Autoheader is > only needed when there is no config.h.in source file (in our case > include/plConfig.h.in), since it is created automatically from the > AC_DEFINE macros seen in configure.ac. I don't understand AC_DEFINE, but I will take your word this makes autoheader unnecessary. > > 4) There is a deprecated file acconfig.h from the top-level directory. We > can happily remove it from the CVS repository. I think there is a bit of value in that file (isinf, for example). Where/how should we do the same thing without that file? > Another unrelated bizarre thing is the command "touch include/plConfig.h.in" > in bootstrap.sh. From the CVS log, this was introduced in the AM-LT branch, > as a workround for problems that I found with autoheader (see > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plplot/plplot/bootstrap.sh?rev=1.1.2.4&content-type=text/vnd.viewcvs-markup) > If autoheader is not called any more in bootstrap.sh, I think that that > touch command should be also removed. Agreed. I had forgotten it was even in bootstrap.sh. (Out of order) > > I have no time to do extensive tests, but implementing the suggestions above > should fix the problem, or at least make a step forward in having a more > sane headers configuration. I will have a bit of time this next weekend (and realistically probably the next as well) to try and implement and test your suggestions if you have run out of further time yourself. I will probably need extra help with (4), but the rest seem straightforward. Of course if Maurice got to it first, that would be great. A lot of this "dog's breakfast" is my fault. I don't understand autoconf so I left a lot of cruft in without much understanding of what was going on. I was just thankful it worked at all. Pulling it apart and removing the duplicate/unneeded bits is probably going to be painful, but I think such an exercise is worthwhile for 5.2.1 and will make us much less sensitive to changes in autotools versions. Rafael, thanks very much for your guidance on what you think is necessary to do (at least as a first step). Maurice, do you concur with these suggested steps? Before Christmas, I believe you had a whole shopping list of autoconf-related changes you wanted to do. Does this work fall in line with that shopping list? I don't want to work against what you wanted to do, but on the other hand, I would like to bring out 5.2.1 fairly soon (this weekend or next depending on how hard it is to implement/test Rafael's suggestions, and how much help I have for doing that). Meanwhile, I need some input from Maurice and/or Geoffrey on what to do with the "touch" workaround. It seems that does work for Joao so I expect my tests (and Maurice's tests) of it tonight will also confirm that. Assuming that, should I overwrite the plplot-5.2.0 tarball and source rpm with the changed date on include/plDevs.h.in? Remember, those files are going to get downloaded a lot before we can bring out 5.2.1. Of course I will be informing plplot-general of the status of the SF file release (if I update those SF files) as well as the workaround. 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: Maurice L. <mj...@ga...> - 2003-01-27 23:43:09
|
Alan W. Irwin writes: > On Mon, 27 Jan 2003, Rafael Laboissiere wrote: > > > I have plunged more deeply into the header configuration problem. I seems > > that that are several small independent problems and the conjunction of some > > of them may have been triggering the bug observed by Joao. Let us see which > > are those problems: > > > > 1) AC_CONFIG_HEADERS should be used in place of AM_CONFIG_HEADER in > > configure.ac. I guess that the use of the deprecated AM_CONFIG_HEADER is > > harmful with the present version of autoconf/automake, but who nows. > > Can you give a reference for the "deprecated". I have the impression you > are correct, but when I looked for it last night I got two stories, (from > info automake) AM_CONFIG_HEADER required and AM_CONFIG_HEADER optional. I > am sure I have also seen the story "deprecated", but can you remind me where? BTW I tried this suggestiong but found that AC_CONFIG_HEADERS doesn't solve the problem at hand.. I still get: Making all in include cd .. && /bin/sh /home/mjl/dev/plplot/latest/missing --run autoheader > Maurice, do you concur with these suggested steps? I think there are still a lot of outstanding issues. > Before Christmas, I > believe you had a whole shopping list of autoconf-related changes you wanted > to do. Does this work fall in line with that shopping list? I don't want > to work against what you wanted to do, but on the other hand, I would like > to bring out 5.2.1 fairly soon (this weekend or next depending on how hard > it is to implement/test Rafael's suggestions, and how much help I have for > doing that). This stuff is mostly orthogonal to the stuff I was looking at, which included: - support for --with-warn, --with-profile, etc - better support for non-GNU compilers (e.g. KCC) - separation of internal-use-only configuration info from headers exported to the public namespace - proper include guards for headers The latter one does overlap with the plConfig.h / plDevs.h problem tho. I really have no idea when I'm going to be able to work on any of that, as I have features work to do and can hack my way around the config issues for now. > Meanwhile, I need some input from Maurice and/or Geoffrey on what to do with > the "touch" workaround. It seems that does work for Joao so I expect my > tests (and Maurice's tests) of it tonight will also confirm that. Assuming > that, should I overwrite the plplot-5.2.0 tarball and source rpm with the > changed date on include/plDevs.h.in? Yes. > Remember, those files are going to get > downloaded a lot before we can bring out 5.2.1. Of course I will be > informing plplot-general of the status of the SF file release (if I update > those SF files) as well as the workaround. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-01-28 08:29:55
|
* Maurice LeBrun <mj...@ga...> [2003-01-27 17:41]: > BTW I tried this suggestiong but found that AC_CONFIG_HEADERS doesn't solve > the problem at hand.. I still get: > > Making all in include > cd .. && /bin/sh /home/mjl/dev/plplot/latest/missing --run autoheader You are right. I investigated this issue more deeply and discovered that Automake always include in include/Makefile.in a rule for rebuilding the files defined in AC_CONFIG_HEADERS using autoheader. For now, I did not discover how to disable this. Now, if the call to autoheader that you metion above only happens for developper, that is okay, since it will be harmless. What is very important for us right now is to get a source tarball for which autoheader is not called when users run configure/make. > This stuff is mostly orthogonal to the stuff I was looking at, which > included: > [...] > - separation of internal-use-only configuration info from headers exported > to the public namespace > - proper include guards for headers > > The latter one does overlap with the plConfig.h / plDevs.h problem tho. Since you are reluctant to incorporate plDevs.h into plConfig.h (and I understand your arguments), we must find a way to get the Autotools (in this case Automake specifically) to behave correctly with two configuration header files. One of the things that is strange now is that all the PLD_* #defines are duplicated in plConfig.h.in and plDevs.h.in. That is possibly a screw-up of mine in the past. -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-01-28 08:16:11
|
* Alan W. Irwin <ir...@be...> [2003-01-27 15:07]: > Can you give a reference for the "deprecated". I have the impression you > are correct, [...] Three references: 1) When you run autoheader (from autoconf package version 2.57) on configure.ac with AM_CONFIG_HEADER instead of AC_CONFIG_HEADERS, you get the error message: $ autoheader autoheader2.50: error: AC_CONFIG_HEADERS not found in configure.ac 2) It is mentioned on one of the files of automake 1.7: $ fgrep AM_CONFIG_HEADER /usr/share/aclocal-1.7/header.m4 # AM_CONFIG_HEADER is obsolete. It has been replaced by AC_CONFIG_HEADERS. 3) In the Automake documentation: $ info -f /usr/share/info/automake-1.7.info-1.gz -n Optional > [...] but when I looked for it last night I got two stories, (from info > automake) AM_CONFIG_HEADER required and AM_CONFIG_HEADER optional. I am > sure I have also seen the story "deprecated", but can you remind me where? Automake-1.7 still implements AM_CONFIG_HEADER for backwards compatibility. > I think there is a bit of value in that file (isinf, for example). > Where/how should we do the same thing without that file? Well, I get here: $ fgrep ISINF acconfig.h include/plConfig.h.in acconfig.h:#undef HAVE_ISINF include/plConfig.h.in:#undef HAVE_ISINF Actually, acconfig.h is fully contained in include/plConfig.h.in. This is why I think it is useless (just run diff -u acconfig.h include/plConfig.h.in to convince yourself). > A lot of this "dog's breakfast" is my fault. I don't understand autoconf so > I left a lot of cruft in without much understanding of what was going on. I > was just thankful it worked at all. It is also partly my fault, since I have let you play the Sorcerer's Apprentice without much guidance. Of course, I foolishly forgot my AM-LT magic hat in the CVS repository and now the splinters of the broom are popping out everywhere... Fairy-tale analogies apart, the Autotools have evolved quite a lot since I started the AM-LT branch in the PLplot repository. I am quite sure that are other obsolete constructs remaining in many places. > Meanwhile, I need some input from Maurice and/or Geoffrey on what to do > with the "touch" workaround. It seems that does work for Joao so I expect > my tests (and Maurice's tests) of it tonight will also confirm that. > Assuming that, should I overwrite the plplot-5.2.0 tarball and source rpm > with the changed date on include/plDevs.h.in? Remember, those files are > going to get downloaded a lot before we can bring out 5.2.1. Of course I > will be informing plplot-general of the status of the SF file release (if I > update those SF files) as well as the workaround. I agree that a new interim release has to be done as soon as possible. I would be reluctant though to replace the tarball by another one with the same name. First, I even do not now if this is possible in the SF "Files" interface. Second, giving two different things the same name would only lead to confusion. You might set in it another VERSION string like "5.2.0-rev1", or whatever. On the other hand, just bumping the number to 5.2.1 with just a change in a file's date is an overkill. -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-01-28 09:31:19
|
[Replying to myself:] * Rafael Laboissiere <lab...@ps...> [2003-01-28 09:06]: > I agree that a new interim release has to be done as soon as possible. I > would be reluctant though to replace the tarball by another one with the > same name. First, I even do not now if this is possible in the SF "Files" > interface. Second, giving two different things the same name would only > lead to confusion. You might set in it another VERSION string like > "5.2.0-rev1", or whatever. On the other hand, just bumping the number to > 5.2.1 with just a change in a file's date is an overkill. I have not seen Alan's announcement to the plplot-general mailing list. It seems that my suggestion above came too late. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-01-28 16:37:49
|
On Tue, 28 Jan 2003, Rafael Laboissiere wrote: > I have not seen Alan's announcement to the plplot-general mailing list. It > seems that my suggestion above came too late. I wasn't absolutely sure myself on this issue, but once Maurice agreed this was the right thing to do, I just went ahead. I think it will be okay. Alan |
From: Maurice L. <mj...@ga...> - 2003-01-27 23:30:41
|
Rafael Laboissiere writes: > 2) The file include/plDevs.h is totally useless since all of its definitions > are already duplicated in include/plConfig.h. I would recommend to > delete taht file from the repository (or actually include/plDevs.h.in) > and replace all inclusions of plDevs.h by plConfig.h. The files > concerned by this change are drivers/*.c, > bindings/tk/{plserver.h,tcpip.c}, include/plcore.h, and src/plfreetype.c. > Also, remove include/plDevs.h from the call to AC_CONFIG_HEADERS in > configure.ac and from the list pkginclude_HEADERS in include/Makefile.am. I would prefer to see the device stuff vanish from plConfig.h instead. Certainly this new, "powerful" configuration system can handle more than one generated header file! BTW I just ran into another irritating side effect of the current configuration system. Running a recursive search from the top level shows up HAVE_CONFIG_H defined throughout: ./bindings/c++/Makefile:DEFS = -DHAVE_CONFIG_H ./bindings/f77/Makefile:DEFS = -DHAVE_CONFIG_H ./bindings/java/Makefile:DEFS = -DHAVE_CONFIG_H ... Well the problem occurs when including headers from some gnu tools such as readline. In /usr/include/readline/tilde.h -- #if defined (HAVE_CONFIG_H) # include <config.h> #endif Whoops. I guess when this happens we'll just have to #undef HAVE_CONFIG_H but that seems pretty lame.. is there any way to turn off this define? I grepped for all the packages on my RH 7.3 system that do this and came up with the following list: /usr/include/kde/ksslcertificate.h:#ifdef HAVE_CONFIG_H /usr/include/kde/ksslpkcs12.h:#ifdef HAVE_CONFIG_H /usr/include/kde/ksslutils.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/decoder/cddaPlugin.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/decoder/vorbisPlugin.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/frame/audioFrame.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/frame/rawFrame.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/input/cddaInputStream.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/oggvorbis/vorbisDecoder.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/oggvorbis/oggFrame.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/oggvorbis/ovFramer.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/oggvorbis/vorbisInfo.h:#ifdef HAVE_CONFIG_H /usr/include/kde/mpeglib/util/abstract/abs_thread.h:#ifdef HAVE_CONFIG_H /usr/include/kde/ksslpemcallback.h:#ifdef HAVE_CONFIG_H /usr/include/kde/ksslpkcs7.h:#ifdef HAVE_CONFIG_H /usr/include/gkrellm/gkrellm.h:#ifdef HAVE_CONFIG_H /usr/include/readline/chardefs.h:#if defined (HAVE_CONFIG_H) /usr/include/readline/chardefs.h:#endif /* !HAVE_CONFIG_H */ /usr/include/readline/tilde.h:#if defined (HAVE_CONFIG_H) -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-01-28 11:14:18
|
* Maurice LeBrun <mj...@ga...> [2003-01-27 17:29]: > BTW I just ran into another irritating side effect of the current > configuration system. Running a recursive search from the top level > shows up HAVE_CONFIG_H defined throughout: > > ./bindings/c++/Makefile:DEFS = -DHAVE_CONFIG_H > ./bindings/f77/Makefile:DEFS = -DHAVE_CONFIG_H > ./bindings/java/Makefile:DEFS = -DHAVE_CONFIG_H > ... > > Well the problem occurs when including headers from some gnu tools such as > readline. In /usr/include/readline/tilde.h -- > > #if defined (HAVE_CONFIG_H) > # include <config.h> > #endif > > Whoops. I guess when this happens we'll just have to #undef HAVE_CONFIG_H > but that seems pretty lame.. is there any way to turn off this define? I think that there is a logical justification for having this define, provided that we proceed like it is advised in the autoconf documentation. We should replace all instances of `#include "plConfig.h"', by: #if HAVE_CONFIG_H # include <plConfig.h> #endif (cf info -f /usr/share/info/autoconf.info.gz -n "Configuration Headers") I am making the assumption that all the definitions in plConfig.h are useful only when compiling PLplot itself and are irrelevant for user's applications linked against PLplot. Is that true? -- Rafael |