Steven G. Johnson wrote: > > On Tue, 29 Oct 2002, Andreas Buening wrote: > > 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. > > Portable preprocessed Fortran is indeed an important (and tricky) > question, but one which (I think) is a separate problem from the present > one of just finding a Fortran compiler, etcetera.
Not really. If you have preprocessed Fortran files then "finding a compiler" means "finding a compiler with preprocessing". Otherwise that compiler is useless (and you should proceed with your search). > Regarding the inference of dialect from file ending, I thought the main > problem would be that if you use .f the compiler might interpret it as > fixed-format...which is "solved" by using .f for legacy code (F77) and > .f90 or whatever for newer code. Is there any F90+ compiler that doesn't > interpret .f90 as F90 source?? xlf90, IBM's compiler for AIX. It requires -qsuffix=f=f90. > The general problem of finding a flag to force free-format/fixed-format > interpretation is an issue for another macro, I think. This means you need a "database", one different flag for every compiler. > > 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. > > I know. This problem already exists in the present autoconf, because > you may want to link with Fortran libraries that are compiled with > different compilers, etcetera. The basic idea is that you use the "default" system compiler that has (hopefully) been used to compile all those system libraries. ;-) > > 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. > > Ultimately, this sort of thing has to be handled by custom macros, if the > maintainer needs particular nonstandard language features. Particularly > common needs might go into the macro repository and from there (maybe) > make their way into the standard autoconf. In other words: You need a "database". > > 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. > Not necessarily. You can try compiling a small test program exhibiting > the feature you want, looping through the possible flags from different > systems/compilers until one works. This is how AC_PROG_CC_STDC works, for > example. Some compilers (like f95n) try to find out the source file format (fixed/free) themselves. For a "print *, 'hello, world'" test program this might work correctly but for a more complicated source file it might fail. In this case there is no possibility for autoconf to find out whether that compiler can really handle fixed/free format. Bye, Andreas
