Support additional file extensions #250
Comments
|
On second thought, most compilers provide flags which allow to select fixed- or free-form format, meaning we could try and implement this without the need to rename files (e.g. if fpm doesn't have write access). But perhaps printing an message to the user would shift the community in the direction of adopting the compatible extensions. |
|
Alternatively, we could decide on a minimal set compatible for all compilers and allow explicit extension / overwriting on per project basis in the package manifest (some projects use |
|
Good point. I recall now the dbcsr uses the So we should agree on some sane default behavior and allow the package developers to use whatever file extensions and source code format they want via the manifest. |
ivan-pi
changed the title
|
Here is a table of the respective compiler options for controlling input source format and preprocessing:
For fixed-form the default line length is 72. For free-form the default line lengths differ between compilers (132, 255, or any). The preprocessors are not fully compatible between compilers. |
|
Added NVHPC/PGI compilers, which additionally support .cuf for CUDA Fortran and .CUF for preprocessed CUDA Fortran. |
|
In the blog post from Steve, there is a link to a post from Intel: Problem: Fortran source files not compiled when building in Visual Studio, which shows how the source and header file extensions are specified in Visual studio. I haven't studied the manifest or TOML syntax closely, but I imagine this would mean introducing something like this: [build]
source.free = [".f90", ".f03", ".f08"]
source.fixed = [".f", ".f77"]
|
|
I would remove the dot from the extension, but the general syntax looks good to me. We will probably need additional entries for the preprocessed files as well: [build.source]
free = ["f90", "f03", "f08"]
free-preprocess = ["F90", "F03", "F08", "fypp"] # or free-pp
fixed = ["f", "f77"]
fixed-preprocess = ["F", "F77", "fpp"] # or fixed-pp |
|
I agree that is cleaner. With respect to the preprocesser, I think we might need to distinguish between external preprocessors (like fypp, or preform) and those built into the compiler (C-like macro processors). Interestingly, |
|
The preprocessor and its operation mode ( |
|
Unless the names are treated differently I am a strong advocate for just ..f|.F|.F90|.f90. If specifying a suffix like .f03 meant Fortran was required to strictly apply the standard as specified for that standard version (which is not the case as far as the standard is concerned) I do not like the other extensions. For a package that is intended to be designed for use by others I think I prefer the user being required to do the preprocessing themselves and only present .f|.f90 files to fpm unless fpm bundles a "standard" preprocessor(s). For fpm use building a local package I'm not quite as strong an advocate for that. |
|
Sun used to distribute an fpp command that was written in Fortran if I recall. I use my own. 96% of my Fortran files are actually .ff and .FF files that run through a preprocessor but a lot of experience has shown me you only distribute .f90 and .f files unless there is no alternative. |
Personally, I agree with sticking to ".f" for fixed, and ".f90" for free form. Definitely, we should not tie the extensions to specific language standard. However, I am afraid that among developers there is not total consensus. As Steve notes in his blog post: "as far as the standard was concerned, source lines were delivered to the “processor” (compiler) by fairies in the night.", which I believe is still true today. The file extensions are merely a default set by compiler vendors. Misconceptions concerning file extensions and the Fortran language standards pop up routinely on comp.lang.fortran, Stack Exchange, r/Fortran, and now even on our Discourse. Admittedly, when I started to learn Fortran for CFD, I used the ".f95" extension. At that time I had never heard of Linux before, nor had I used the command line. The lowest entry point I could find was the Silverfrost FTN95 compiler on Windows. The example programs used the ".f95" extension. In fact, I was not even aware that modern editions of Fortran existed, as all the examples I could find on the internet were procedural style CFD codes in F77 or F90. Only recently (three years ago!), when I got access to the Intel Fortran compiler at my university, I found out I need to use the ".f90" extensions to have things work automatically. At the same time you have some respectable Fortran codebases (like cp2k), which bypass the default compiler options, and use ".F" even for free-form. Since
Personally, I am in favor of the first option. As a beginner in Fortran, this would nudge me in the right direction. Speaking of option 2, it seems like a fun project with neural-fortran, the input to the neural network could be the number of |
|
I like the neural-fortran idea better; but you just reminded me of some elaborate make(1) files I inherited that were all set up for the Intel compiler except these lines that called "gfortran -fsyntax-only ..." with the output module files thrown into a scratch directory and then erased and a bunch of other oddities. It took a moment looking at the subsequent lines to see he was compiling the code with syntax checking with gfortran only and forcing -ffixed-form (or whatever the option is) and if it failed the syntax check he was assuming it was free-form. A dangerous game but apparently it worked the way he wanted. We took it out and renamed the files and changed a few other parts that had .ftn and such built into them. Not recommending anyone use that method! He had been moving a large amount of F77 code to free-format and apparently got tired of renaming the files and making related changes, I think. Several compilers allow for directives in the source files to specify fixed versus free format at least down to the level of a single procedure. When changing old large multi-procedure files that is particularly handy (versus splitting them all apart of having to rewrite them all, and so on). If you are grabbing fixed-format codes and merging them into modules that is initially very useful. If would be nice when free-format was introduced if that had been an attribute you could specify at the beginning of a procedure definition, like but specifying a code syntax attribute and function attributes together would probably not appeal to everyone. |
I guess this is the right approach for small to medium size libraries, that only aim to provide Fortran procedures. Still we cannot exclude the use of a preprocessor for purposes like conditional compilation depending upon platform, compiler version, or other uses (compile-time selection of precision, using a different back-end library). I think with fpm we would also like to enable Fortran users to exchange templates and macros. |
@ivan-pi , Please keep |
Once
fpmwill be out in the wild, we should try to support other Fortran file extensions.This is not so important right now, but I thought I will create an issue since I gathered the information.
Here is a table of file extensions with default support by different compilers:
The only options that are compatible along the tool-chains listed above are:
.f,.F,.f90,.F90.The
.ftnextension has a clash betweengfortran,ifort, andnagforwhich assume fixed-form, and Cray which assumes free-form.To enhance portability between compilers, we should either allow
fpmto (copy and) rename the files silently, or havefpmprint a message to the user to consider renaming his files.Blog posts related to this issue:
Edit: Feel free to add more compilers.
The text was updated successfully, but these errors were encountered: