Steven G. Johnson wrote: > > With each year that goes by, the need to address this issue in autoconf > and automake increases. We need to make a decision, especially since > people keep submitting patches with conflicting strategies for this issue. > > Kate Hedstrom wrote: > > It seems to me that the compiler name of $F77 is unfortunate in that it > > cries out for $F90 and $F95 friends. Some versions of make use $FC > > instead - can we change the $F77? Ignoring that everything is called f77, > > I could use fortran.m4 as it stands if the compiler search were reversed, > > with f95 first and f77 last. Bill Wendling's module check is a useful > > addition, as is the f95 forall check. > > Every time this issue comes up, there are various people who come out of > the woodwork to say that they need to compile both Fortran 77 and F9x in > the same project, where the former are legacy codes written in ways > incompatible with the newer standards.
It looks like I'm also one of those people and I've to come out of the woodwork. ;-) > On the other hand, it is completely crazy to have a new F?? for every > revision of the Fortran standard. Moreover, the newer revisions seem to > be much more compatible with one another, so that most(?) F90 codes will > compile under F95, etcetera, and more importantly they seem less likely > to be mixed in a single project. Most likely. > I've been thinking about this, and my suggestion is: > > 1) Have two compilers, F77 and FXX, where the former tries to be F77 > (i.e. the current behavior) while the latter is selected by > AC_PROG_FXX([year], [search-list]), where year is YY or YYYY with YY < > 54 interpreted as 20YY, and with the default year being the latest > supported Fortran standard. Unknown years trigger an error. (Have > $FXXFLAGS etc. in analogue to $FFLAGS etc.) Rationales: [snip] It would be nice to be able to compile f90 programs with autoconf. If you can implement this, please, feel free to do it. I can't tell about "general fortran projects" but I can tell you about the project I have to use for my work. It uses f90 code I've written mostly myself, f77 legacy code for the program "core" that is incompatible with any f9x compiler and some C code for system tasks. I'd like to use autoconf for it but I don't think it'll be possible with the current autoconf design. It's not just the problem that you have to find two different compilers, one for the f77, one for the f9x source files, it's also the problem to find the compiler options you need. With C it's not a real problem. On most systems "-g -O2" will work and "-O2 -s" will be fine. But with Fortran it's much more difficult. You may have some f77 files that have to be preprocessed (e.g. ".F" file extension), you may have also some f77 files that have NOT to be preprocessed (due to compiler bugs; I have this problem). You may have f90 files in free format, others in fixed format but you have just a few file extensions (.f, .F, .f90, .F90) to signal which file has to be handled which way. You may specify this behaviour in AC_PROG_FXX. Some compilers may not recognize several file extension or may have a hardcoded default which file extension implies which dialect/source format. So you may have to find out the compiler option to tell the compiler that .f90 is a f90 file and not an object file. You may have to find out which options turns the preprocessor on/off and how you can forward macros to the preprocessor, not every compiler supports -D__FOO__. Maybe the compiler supports different preprocessors but just one of them is installed. You may have to find out how to switch between fixed format and free source format. For some compilers -I/some/dir might not be sufficient to find "include" files. You may need special options for code that is not standard compliant, e.g. to tell the compiler that a declaration real(4) means that this variable really has a size of 4 bytes. If you compile that code on a 64 bit cpu you might have to tell the compiler to use 32 bit integers. But it's even worse. It's not that AC_PROG_F77 and AC_PROG_FXX are independent of each other. If you find a f9x compiler of a specific vendor you have to use also the f77 compiler of the same vendor. E.g. you can't link files compiled with g77 and f95n (NAGWare) because both rely on their own internal library and both don't know of each other. At the end you have the problem that only the maintainer knows which features he needs and only the user (if at all) knows which compiler options provide which feature on his system. If the maintainer wants to have a portable installation mechanism he has to write a script (or at least a database) which system and which compiler requires which set of options for which kind of source file and which compiler. But that's completely opposite to the autoconf philosophy to write one generic configure.ac and every user can specify his extra options if he wants. Just my 2 cents. Bye, Andreas
