From: Alan W. I. <ir...@be...> - 2006-05-16 03:13:10
Attachments:
patch1.out
patch2.out
|
As a result of my post to the libtool list describing the troubles I was having with the CVS version of libtool, Ralf Wildenhues, an active autotools developer, was kind enough to review our configuration system. He recommended a number of minor improvements plus he also recommended one major change; we needed to change the order we call macros to conform to the order recommended in the autotool's documentation. The CVS version of libtool (which will soon turn into libtool-2.0) demands this correct order should be used. I discussed these changes with Rafael, and he approved subject to my testing them. My tests were good so I have just now cvs committed the results. (Rafael, I briefly considered your further recommendation about widespread replacement of our usual if test ... fi construct with the AS_IF macro that Ralf introduced to us, but I think that is too much change at the present time.) Comparison between a build using the current cvs version versus this morning's version showed no differences except the latest version forces "-lm' to be used almost everywhere for linking. We have had trouble before with -lm not appearing when needed for some systems so this change may be beneficial. The installed examples for a heavily loaded PLplot system with all language interfaces deployed built with no obvious problems and gave identical results to the old system. IMPORTANT. However, more testing of this new autotools macro ordering is required on additional platforms so I hope the developers here do this in the next few days to make sure these changes have introduced no problems. Furthermore, with the above changes now committed to CVS, only a tiny amount of further change is required to get a good build with the CVS version of libtool. I have attached two small patch files that need to be applied to PLplot in order to use the CVS version of libtool. I have indicated before on this list how to download (with wget), build, and install the CVS version of libtool. If you then apply the two attached patches to an experimental tree for PLplot, you should be able to build a full system with gfortran with no problems (at least that was my experience). Of course, these small PLplot patches and the CVS version of libtool have nothing to do with our forthcoming release, but still I agree with Andrew's argument that the commercial fortran compiler issues that we currently have are important to fix, and I am curious if the latest CVS version of libtool along with the attached patches will do that. So, Andrew, I hope you give ifort and pgf90 a try with CVS libtool and patched PLplot. Alan __________________________ Alan W. Irwin 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 __________________________ |
From: Andrew R. <and...@us...> - 2006-05-16 07:27:44
|
On Mon, May 15, 2006 at 08:13:07PM -0700, Alan W. Irwin wrote: > > Of course, these small PLplot patches and the CVS version of libtool have > nothing to do with our forthcoming release, but still I agree with Andrew's > argument that the commercial fortran compiler issues that we currently have > are important to fix, and I am curious if the latest CVS version of libtool > along with the attached patches will do that. So, Andrew, I hope you give > ifort and pgf90 a try with CVS libtool and patched PLplot. Alan, The ifort issues turn out not to be libtool problems. With libtool 1.5.22 I can get ifort to work provided I either - rename all .f95 files to .f90. or - I force the Makefile to use the -FR -Tf options for ifort. Note that -FR forces free-form source files while -Tf forces the following source file to be assumed to be fortran, irrespective of the file extension. Note that -Tf must appear directly before the source file name. With one of these changes all the bindings and example compile without problems. Alan, which approach do you prefer? If it is the latter, does anyone have any recommendations as to the best way to achieve this, particularly to ensure -Tf is followed by the source file name. ifort did uncover a bug in sfstubsf95.f95 with plfill3, now corrected in CVS. I will now test with pgf90. Andrew |
From: Andrew R. <and...@us...> - 2006-05-16 08:03:33
|
On Tue, May 16, 2006 at 08:27:28AM +0100, Andrew Ross wrote: > On Mon, May 15, 2006 at 08:13:07PM -0700, Alan W. Irwin wrote: > > > > Of course, these small PLplot patches and the CVS version of libtool have > > nothing to do with our forthcoming release, but still I agree with Andrew's > > argument that the commercial fortran compiler issues that we currently have > > are important to fix, and I am curious if the latest CVS version of libtool > > along with the attached patches will do that. So, Andrew, I hope you give > > ifort and pgf90 a try with CVS libtool and patched PLplot. > > Alan, > > The ifort issues turn out not to be libtool problems. With libtool > 1.5.22 I can get ifort to work provided I either > > - rename all .f95 files to .f90. > > or > > - I force the Makefile to use the -FR -Tf options for ifort. Note > that -FR forces free-form source files while -Tf forces the following > source file to be assumed to be fortran, irrespective of the file > extension. Note that -Tf must appear directly before the source file > name. > > With one of these changes all the bindings and example compile without > problems. > > Alan, which approach do you prefer? If it is the latter, does anyone > have any recommendations as to the best way to achieve this, > particularly to ensure -Tf is followed by the source file name. > > ifort did uncover a bug in sfstubsf95.f95 with plfill3, now corrected > in CVS. > > I will now test with pgf90. Same results with pgf90. Works fine provided .f95 -> .f90. I can't find a command line option with pgf90 version 4 to do this though. Note the latest version is now v6, which does recognise .f95 I believe. Version 4 is getting a little old now. Again, I uncovered another "bug" in sfstubsf95.f95. Now fixed in CVS. So if we can sort out this .f95 / .f90 issue then the F95 bindings should work for at least 2 of the main commercial fortan compilers, provided of course that F77 and FC are both set to the same thing. Andrew |
From: Arjen M. <arj...@wl...> - 2006-05-16 10:06:56
|
Hi all, I apologize for yet another error report: on my system I also lack LASi - nevertheless ./configure includes the psttf driver. The build then fails at that point. I have the various output files for inspection. Now I will continue without psttf. Regards, Arjen |
From: Rafael L. <rla...@us...> - 2006-05-16 20:40:18
|
* Arjen Markus <arj...@wl...> [2006-05-16 12:06]: > I apologize for yet another error report: > on my system I also lack LASi - nevertheless ./configure includes the psttf > driver. The build then fails at that point. This happens because only enable_psttf is set to "no" after the check for LASi fails, while enable_psttfc is unaffected (i.e. keeps its default value "yes"). A trivial patch to fix this is: --- drivers-init.ac 12 May 2006 19:11:22 -0000 1.16 +++ drivers-init.ac 16 May 2006 20:30:08 -0000 @@ -77,7 +77,7 @@ pbm:pbm:yes, plmeta:plmeta:yes, ps:ps:yes, psc:ps:yes, - psttf:psttf:yes, psttfc:psttf:yes, + psttf:psttf:yes, pstex:pstex:yes, xterm:tek:no, tek4010:tek:no, tek4107:tek:no, mskermit:tek:no, versaterm:tek:no, vlt:tek:no, conex:tek:no, tek4010f:tek:no, After applying this patch, the --enable-psttfc option is dropped and only psttf will appear in the "devices:" line of the configure summary. I do not think that this is problematic, because the psttf and the psttfc devices cannot exist one without the other. Another solution would be to change cf/psttf.ac to set enable_psttfc according to the value of enable_psttf. IMO, this is an overkill. I let the final decision to Andrew, at any event. -- Rafael |
From: Andrew R. <and...@us...> - 2006-05-16 22:48:49
|
On Tue, May 16, 2006 at 10:40:12PM +0200, Rafael Laboissiere wrote: > * Arjen Markus <arj...@wl...> [2006-05-16 12:06]: > > > I apologize for yet another error report: > > on my system I also lack LASi - nevertheless ./configure includes the psttf > > driver. The build then fails at that point. > > This happens because only enable_psttf is set to "no" after the check for > LASi fails, while enable_psttfc is unaffected (i.e. keeps its default value > "yes"). A trivial patch to fix this is: > > --- drivers-init.ac 12 May 2006 19:11:22 -0000 1.16 > +++ drivers-init.ac 16 May 2006 20:30:08 -0000 > @@ -77,7 +77,7 @@ > pbm:pbm:yes, > plmeta:plmeta:yes, > ps:ps:yes, psc:ps:yes, > - psttf:psttf:yes, psttfc:psttf:yes, > + psttf:psttf:yes, > pstex:pstex:yes, > xterm:tek:no, tek4010:tek:no, tek4107:tek:no, mskermit:tek:no, > versaterm:tek:no, vlt:tek:no, conex:tek:no, tek4010f:tek:no, > > > After applying this patch, the --enable-psttfc option is dropped and only > psttf will appear in the "devices:" line of the configure summary. > I do not think that this is problematic, because the psttf and the psttfc > devices cannot exist one without the other. > > Another solution would be to change cf/psttf.ac to set enable_psttfc > according to the value of enable_psttf. IMO, this is an overkill. I let > the final decision to Andrew, at any event. I only added the psttfc option in at Alan's request so it was consistent with the ps driver and showed both in config.summary. For now I have just added enable_psttfc=no to cf/psttf.ac. Andrew |
From: Alan W. I. <ir...@be...> - 2006-05-16 23:58:02
|
On 2006-05-16 23:48+0100 Andrew Ross wrote: > On Tue, May 16, 2006 at 10:40:12PM +0200, Rafael Laboissiere wrote: >> Another solution would be to change cf/psttf.ac to set enable_psttfc >> according to the value of enable_psttf. IMO, this is an overkill. I let >> the final decision to Andrew, at any event. > > I only added the psttfc option in at Alan's request so it was consistent > with the ps driver and showed both in config.summary. For now I have > just added enable_psttfc=no to cf/psttf.ac. It's funny all three of us were working on this at once. I would like to keep the distinction between enable_psttfc and enable_psttf since that is what we do for every other device. If you look at gd.c and tek.c this is carried even further with bits and pieces of the code compiled or not depending on this fine-grained device (as opposed to coarse-grained device-driver) control. I have just committed a slight improvement to Andrew's fix of cf/psttf.ac, and also I am about to commit a small change to psttf.cc so that code gets compiled (via PLD_psttf and PLD_psttfc) if either enable_psttfc or enable_psttfc is set to yes. Alan __________________________ Alan W. Irwin 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 __________________________ |
From: Rafael L. <rla...@us...> - 2006-05-17 06:46:24
|
* Alan W. Irwin <ir...@be...> [2006-05-16 16:56]: > I have just committed a slight improvement to Andrew's fix of cf/psttf.ac, > and also I am about to commit a small change to psttf.cc so that code gets > compiled (via PLD_psttf and PLD_psttfc) if either enable_psttfc or > enable_psttfc is set to yes. Have you committed this change already? I still see in psttf.cc: char* plD_DEVICE_INFO_psttf = "psttf:PostScript File (monochrome):0:psttf:55:psttfm\n" "psttfc:PostScript File (color):0:psttf:56:psttfc"; which means that both devices will always be present together. This makes the doubling of configure options moot, since both: ./configure --enable-psttf --disable-psttfc and ./configure --disable-psttf --enable-psttfc are equivalent to: ./configure --enable-psttf --enable-psttfc or ./configure (since both options have "yes" as default value). I do not understand the need to have separate configure options for psttf and psttfc. The argument that it is already done for ps and psc is quite weak. Notice that the situation of the gd driver is completely different, because each of its devices (png, jpeg, etc) depend on different libraries, which is not the case of psttf and psttfc. In sum: KISS, please. -- Rafael |
From: Andrew R. <and...@us...> - 2006-05-17 06:57:50
|
I think on the whole I'm with Rafael on this one. These are not really two different drivers at all. It's just a option (which you can add on the command line) to switch between monochrome and colour. Just having one --enable-psttf option would make life much simpler. The _only_ reason for having two options is so that psttf and psttfc appear in the drivers list in the summary. There is some slight benefit in being able to use psttf and psttfc as -dev options since it is a very common thing to produce monochrome ps for publication etc. For this reason it would be nice to keep the code char* plD_DEVICE_INFO_psttf = "psttf:PostScript File (monochrome):0:psttf:55:psttfm\n" "psttfc:PostScript File (color):0:psttf:56:psttfc"; in psttf.c. This doesn't fit neatly into our current driver model though. Currently the postscript driver is broken in precisely the same way. It's just that nobody ever tries to disable this (why would you?) and so nobody has pointed it out. Andrew On Wed, May 17, 2006 at 08:46:17AM +0200, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2006-05-16 16:56]: > > > I have just committed a slight improvement to Andrew's fix of cf/psttf.ac, > > and also I am about to commit a small change to psttf.cc so that code gets > > compiled (via PLD_psttf and PLD_psttfc) if either enable_psttfc or > > enable_psttfc is set to yes. > > Have you committed this change already? I still see in psttf.cc: > > char* plD_DEVICE_INFO_psttf = > "psttf:PostScript File (monochrome):0:psttf:55:psttfm\n" > "psttfc:PostScript File (color):0:psttf:56:psttfc"; > > which means that both devices will always be present together. This makes > the doubling of configure options moot, since both: > > ./configure --enable-psttf --disable-psttfc > > and > > ./configure --disable-psttf --enable-psttfc > > are equivalent to: > > ./configure --enable-psttf --enable-psttfc > > or > > ./configure > > (since both options have "yes" as default value). > > I do not understand the need to have separate configure options for psttf > and psttfc. The argument that it is already done for ps and psc is quite > weak. Notice that the situation of the gd driver is completely > different, because each of its devices (png, jpeg, etc) depend on > different libraries, which is not the case of psttf and psttfc. > > In sum: KISS, please. > > -- > Rafael > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Rafael L. <rla...@us...> - 2006-05-17 07:20:32
|
* Andrew Ross <and...@us...> [2006-05-17 07:57]: > Currently the postscript driver is broken in precisely the same way. > It's just that nobody ever tries to disable this (why would you?) and > so nobody has pointed it out. Indeed. If I do: ./configure --enable-ps --disable-psc I still get the psc device enabled (i.e. it appears in drivers/ps.rc), even though it is not reported in the summary. This is a very inconsistent behavior and must be fixed. I would then vote to drop both --enable-psc and --enable-psttfc options of configure. -- Rafael |
From: Alan W. I. <ir...@be...> - 2006-05-17 17:28:03
|
On 2006-05-17 09:20+0200 Rafael Laboissiere wrote: > * Andrew Ross <and...@us...> [2006-05-17 07:57]: > >> Currently the postscript driver is broken in precisely the same way. >> It's just that nobody ever tries to disable this (why would you?) and >> so nobody has pointed it out. > > Indeed. If I do: > > ./configure --enable-ps --disable-psc > > I still get the psc device enabled (i.e. it appears in drivers/ps.rc), > even though it is not reported in the summary. This is a very > inconsistent behavior and must be fixed. > > I would then vote to drop both --enable-psc and --enable-psttfc options > of configure. Let's be absolutely clear here. Rafael is requesting a distinct control design where the devices associated with the ps device driver get turned on or off together and similarly for psttf, while the devices associated with all other device drivers are individually controllable. I agree with Rafael that the gd device driver is somewhat of a special case because of the different libraries involved with each separate device, but Rafael's discussion has ignored the tek device driver (8 different individually controlled devices) and the hpgl device driver (3 different individually controlled devices) where there are no special library considerations. I do agree the ps device driver has always been broken with regard to thr current overall fine-grained control of each individual device philosophy and now that problem has propagated to the psttf device driver. However, for the current CVS HEAD all the configuration infrastructure is in place so the problem can be fixed with straightforward use of #ifdef's in the ps.c and psttf.cc code just like is done now for gd.c, tek.c, and hpgl.c. I also see the other side, however. For example, I do agree with Andrew that once the ps.c and psttf.cc #ifdef fixes were in, it would be the rare case where anybody actually used that individual configuration control of the ps, psc, psttf, and psttfc devices. And similarly for the 11 individual devices implemented by the hpgl and tek device drivers. My view is parallel design ultimately simplifies life for everybody so that is why my instinct has been to keep the current fine-grained configuration infrastructure for all devices and encourage those familiar with ps.c and psttf.c to fix the #ifdefs in those files. But a viable alternative is certainly to make the choice between fine-grained or coarse-grained device control individual for each device driver. But if we decide to go that route let's make it official with a flag for it in cf/drivers-init.ac and documentation in drivers/README.drivers. For now we could turn off the flag for individual control of devices for ps and psttf (and note in drivers/README.drivers you simplify the #ifdef requirements in the corresponding ps.c and psttf.cc files when that flag is off), and leave it on for gd, hpgl, and tek. Another possibility is we could leave the flag turned off for everything except gd. I have laid out some alternatives for dealing with this problem, but ultimately it is going to be up to the one who (a) decides to fix the #ifdefs or (b) decides to fix the configuration to be aware of the control philosophy (ideally through a flag) for each device driver. So Andrew, I say go ahead with the fix that appeals to you the most. Alan __________________________ Alan W. Irwin 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 __________________________ |
From: Rafael L. <rla...@us...> - 2006-05-18 07:10:39
|
* Alan W. Irwin <ir...@be...> [2006-05-17 10:26]: > On 2006-05-17 09:20+0200 Rafael Laboissiere wrote: > > >* Andrew Ross <and...@us...> [2006-05-17 07:57]: > > > >>Currently the postscript driver is broken in precisely the same way. > >>It's just that nobody ever tries to disable this (why would you?) and > >>so nobody has pointed it out. > > > >Indeed. If I do: > > > > ./configure --enable-ps --disable-psc > > > >I still get the psc device enabled (i.e. it appears in drivers/ps.rc), > >even though it is not reported in the summary. This is a very > >inconsistent behavior and must be fixed. > > > >I would then vote to drop both --enable-psc and --enable-psttfc options > >of configure. > > Let's be absolutely clear here. Rafael is requesting a distinct control > design where the devices associated with the ps device driver get turned on > or off together and similarly for psttf, while the devices associated with > all other device drivers are individually controllable. I agree with Rafael > that the gd device driver is somewhat of a special case because of the > different libraries involved with each separate device, but Rafael's > discussion has ignored the tek device driver (8 different individually > controlled devices) and the hpgl device driver (3 different individually > controlled devices) where there are no special library considerations. These two drivers are also broken, because the plD_DEVICE_INFO_tek and plD_DEVICE_INFO_hpgl variables are not treated in a consistent way with the PLD_* directives. For instance, if I do: ./configure --enable-hp7470 --disable-hp7580 I still have the device hp7580 activated. This must be fixed. In both tek.c and hpgl.c, there are many #ifdef directives using the PLD_variables, so you must maintain the fine grained control for those ones. However, the ps and psttf drivers do not use the distinction between monochrome and color at compilation time. If nobody objects, I will soon drop the enable-psc and enable-psttfc options. -- Rafael |
From: Andrew R. <and...@us...> - 2006-05-18 07:30:11
|
On Thu, May 18, 2006 at 09:10:34AM +0200, Rafael Laboissiere wrote: > > These two drivers are also broken, because the plD_DEVICE_INFO_tek and > plD_DEVICE_INFO_hpgl variables are not treated in a consistent way with the > PLD_* directives. For instance, if I do: > > ./configure --enable-hp7470 --disable-hp7580 > > I still have the device hp7580 activated. This must be fixed. > > In both tek.c and hpgl.c, there are many #ifdef directives using the > PLD_variables, so you must maintain the fine grained control for those > ones. However, the ps and psttf drivers do not use the distinction > between monochrome and color at compilation time. > > If nobody objects, I will soon drop the enable-psc and enable-psttfc > options. Rafael, I have no objection to dropping the separate configure options to enable-psc and enable-psttfc, provided the separate devices ps and psc etc still remain. This seems the right thing to do. Allowing you to select one and not the other would be crazy since the code is essentially identical. Ideally it would be nice if config.summary could display something like ps(c) in the driver list to illustrate that these are two drivers, but that you either get both or neither of them. I'm not quite sure if this is possible in the current plplot configuration framework. Andrew |
From: Rafael L. <rla...@us...> - 2006-05-18 08:04:34
|
* Andrew Ross <and...@us...> [2006-05-18 08:30]: > I have no objection to dropping the separate configure options to > enable-psc and enable-psttfc, provided the separate devices ps and psc > etc still remain. This seems the right thing to do. Allowing you to > select one and not the other would be crazy since the code is essentially > identical. I have already done the changes here and will commit them soon after doing some final tests. > Ideally it would be nice if config.summary could display something > like ps(c) in the driver list to illustrate that these are two drivers, > but that you either get both or neither of them. I'm not quite sure if > this is possible in the current plplot configuration framework. No, this is not possible with the current configuration. The changes seem to be non trivial, so that I am not working on this for now. Actually, having the accurate list of devices in the summary is a very minor issue, IMHO. -- Rafael |
From: Andrew R. <and...@us...> - 2006-05-16 22:43:13
|
Arjen, I think I may have fixed this now. Can you check? Thanks Andrew On Tue, May 16, 2006 at 12:06:48PM +0200, Arjen Markus wrote: > Hi all, > > I apologize for yet another error report: > on my system I also lack LASi - nevertheless ./configure includes the psttf > driver. The build then fails at that point. > > I have the various output files for inspection. > > Now I will continue without psttf. > > Regards, > > Arjen > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@wl...> - 2006-05-16 09:58:17
|
Hi all, I ran into an error with gcw on a Linux system that does not have freetype: gcw.c: In function `proc_str': gcw.c:1021: error: `FontLookup' undeclared (first use in this function) gcw.c:1021: error: (Each undeclared identifier is reported only once gcw.c:1021: error: for each function it appears in.) gcw.c:1021: error: `N_TrueTypeLookup' undeclared (first use in this function) make[2]: *** [gcw_la-gcw.lo] Error 1 I checked the source code. The culprit is this fragment: /* Determine the default font */ plgfci(&fci); fontname = plP_FCI2FontName(fci, FontLookup, N_TrueTypeLookup); if (fontname == NULL) { plabort("GCW driver <proc_str>: FCI inconsistent with TrueTypeLookup"); } The table FontLookup only exists if HAVE_FREETYPE is defined. As I am unsure what should be done if freetype is not present, I do not want to change the code myself. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-05-16 19:43:00
|
Arjen, I need a quick response to the question at the end... Alan On 2006-05-16 09:03+0100 Andrew Ross wrote: > So if we can sort out this .f95 / .f90 issue then the F95 bindings > should work for at least 2 of the main commercial fortan compilers, > provided of course that F77 and FC are both set to the same thing. That's wonderful news, Andrew. I have reviewed the various pieces of documentation for the Intel, Absoft, Portland Group, and gfortran compilers. They all claim to be fortran 95 compilers. Also, Absoft, Portland Group (at least its current release), and gfortran accept the .f, .f90, and .f95 suffix. (Fortran 95 code can appear with all suffixes. The .f suffix simply means the code is in fixed format and the .f90 or .f95 suffixes mean it is in free format.) Despite being fortran 95 capable, the Intel compiler only accepts .f and .f90 suffixes (unless you use the impossible [from the autotools point of view] -TfFILENAME option to tell the compiler to not worry about suffixes for the file called FILENAME.) So it appears the the current Intel compiler (unless you use the impossible -Tf option) and the old release of the Portland Group compiler do not accept the .f95 extension, but everything else I have looked at does. Also, it appears that all these fortran 95 compilers accept the .f90 extension. (I have just checked that with gfortran in bindings/f95, and Andrew reports good results for the Intel compiler and old release of the Portland Group compiler.) To allow our users to use the Intel compiler and the old Portland Group compiler, I am leaning toward leaving our f95 directory names intact (to indicate we really do have a fortran 95 interface), but renaming all the present *.f95 files in bindings/f95 and examples/f95 to *.f90 as suggested by Andrew. Arjen, you have a lot more fortran 95 experience than me. Also, you are the original instigator of the fortran 95 interface. Thus, I think it is your call. What do you think is the best thing to do? Alan __________________________ Alan W. Irwin 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 __________________________ |
From: Arjen M. <arj...@wl...> - 2006-05-16 19:50:35
|
> Arjen, I need a quick response to the question at the end... Alan > On 2006-05-16 09:03+0100 Andrew Ross wrote: > > > To allow our users to use the Intel compiler and the old Portland Group > compiler, I am leaning toward leaving our f95 directory names intact > (to indicate we really do have a fortran 95 interface), but renaming > all the present *.f95 files in bindings/f95 and examples/f95 to *.f90 > as suggested by Andrew. > > Arjen, you have a lot more fortran 95 experience than me. Also, you > are the original instigator of the fortran 95 interface. Thus, I think > it is your call. What do you think is the best thing to do? > I think using the extension .f90 instead of .f95 is the way to go. There have been several discussions about the use of the extension as an indicator of the relevant standard on comp.lang.fortran, but consensus is that the distinction should be between fixed form and free form, rather than the standard. So: yes, let us change to .f90 - now is the time to do so Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-05-16 20:36:12
|
On 2006-05-16 21:49+0200 Arjen Markus wrote: >> Arjen, I need a quick response to the question at the end... Alan >> On 2006-05-16 09:03+0100 Andrew Ross wrote: > I think using the extension .f90 instead of .f95 is the way to go. > There have been several discussions about the use of the extension > as an indicator of the relevant standard on comp.lang.fortran, but > consensus is that the distinction should be between fixed form and > free form, rather than the standard. > > So: yes, let us change to .f90 - now is the time to do so Thanks, Arjen, for the quick decision. I have just cvs committed this change. Andrew, please give it a try for the commercial compilers you have access to. Also, Jim please give it a try (when your cvs update on the anonymous cvs server says it has caught up with the name change). Alan __________________________ Alan W. Irwin 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 __________________________ |
From: Andrew R. <and...@us...> - 2006-05-16 22:46:42
|
On Tue, May 16, 2006 at 12:42:36PM -0700, Alan Irwin wrote: > Arjen, I need a quick response to the question at the end... Alan > On 2006-05-16 09:03+0100 Andrew Ross wrote: > > >So if we can sort out this .f95 / .f90 issue then the F95 bindings > >should work for at least 2 of the main commercial fortan compilers, > >provided of course that F77 and FC are both set to the same thing. > > That's wonderful news, Andrew. > > I have reviewed the various pieces of documentation for the Intel, Absoft, > Portland Group, and gfortran compilers. They all claim to be fortran 95 > compilers. Also, Absoft, Portland Group (at least its current release), and > gfortran accept the .f, .f90, and .f95 suffix. (Fortran 95 code can appear > with all suffixes. The .f suffix simply means the code is in fixed format > and the .f90 or .f95 suffixes mean it is in free format.) Despite being > fortran 95 capable, the Intel compiler only accepts .f and .f90 suffixes > (unless you use the impossible [from the autotools point of view] > -TfFILENAME option to tell the compiler to not worry about suffixes for the > file called FILENAME.) > > So it appears the the current Intel compiler (unless you use the impossible > -Tf option) and the old release of the Portland Group compiler do not accept > the .f95 extension, but everything else I have looked at does. Also, it > appears that all these fortran 95 compilers accept the .f90 extension. (I > have just checked that with gfortran in bindings/f95, and Andrew reports > good results for the Intel compiler and old release of the Portland Group > compiler.) > > To allow our users to use the Intel compiler and the old Portland Group > compiler, I am leaning toward leaving our f95 directory names intact (to > indicate we really do have a fortran 95 interface), but renaming all the > present *.f95 files in bindings/f95 and examples/f95 to *.f90 as suggested > by Andrew. > > Arjen, you have a lot more fortran 95 experience than me. Also, you are the > original instigator of the fortran 95 interface. Thus, I think it is your > call. What do you think is the best thing to do? Alan, You'll be pleased to hear that the f95 bindings now work out of the box provided you use configure --enable-f95 FC=ifort F77=ifort Andrew |
From: Bryan P. <pet...@ma...> - 2006-05-16 16:20:17
|
On Mon, 15 May 2006, Alan W. Irwin wrote: > Comparison between a build using the current cvs version versus this > morning's version showed no differences except the latest version forces > "-lm' to be used almost everywhere for linking. We have had trouble before > with -lm not appearing when needed for some systems so this change may be > beneficial. I personally am very glad that the "-lm" is back. On Slackware I have had to edit the configure script for every new install because linking to libjpeg and libgd required that flag so the tests would always fail until I went in and found the correct place to insert it. By the way, I am currently using Intel Fortran 9.0 and Slackware 10.2 and could test the new release on that configuration if it would be useful. Bryan Peterson bry...@by... |
From: Alan W. I. <ir...@be...> - 2006-05-17 01:25:54
|
On 2006-05-16 23:46+0100 Andrew Ross wrote: > Alan, > > You'll be pleased to hear that the f95 bindings now work out of the box > provided you use configure --enable-f95 FC=ifort F77=ifort Yes, I am very pleased by your ifort breakthrough, indeed. (Also a bit surprised since the guru on the libtool list said it couldn't be done with libtool-1.5.22, but perhaps he was referring to the necessity of the F77 workaround that you discovered.) Thanks for your persistence that made ifort possible. Could you make the appropriate change in INSTALL describing this result and the result for pgf90 (when you have the latter)? BTW, even though you have ifort working (and probably pgf90), I still think we should leave f95 disabled by default since the various F77/FC workarounds are a bit tricky. Also, as a post-5.6.1 issue, I am curious whether the F77/FC workarounds are no longer needed for the CVS version of libtool. I have now got PLplot (with the two small patches for cf/bootstrap.sh and cf/libtool.ac that I sent to the list) working fine with that version of libtool on both my systems, but I only have gfortran on one of those systems and I certainly do not have commercial fortran compilers on either system to test. Alan __________________________ Alan W. Irwin 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 __________________________ |