Facility to set/suppress compiler flags on a per-file basis

[ivan-pi]

Would there be any interest in coming up with some comment-based directives to suppress compiler warnings? The idea arose from fortran-lang/stdlib#313 (review)

Even for correct use of the implicit integer to real conversion, the compiler might produce a lot of warnings like:

Warning: Conversion from INTEGER(4) to REAL(8) at (1) [-Wconversion-extra]

I was wondering if this could be turned off using some comment based input directives to fpm like

!fpm:gfortran-flags=["-Wno-conversion-extra"]

Of course, this should only be done, once the code has been thoroughly tested, and it has been verified the warnings are redundant.

[ivan-pi]

On the other hand, this might be dangerous, if people start relying upon directives like (see #434):

!fpm:gfortran-flags=["-fdefault-real-8"]
!fpm:ifort-flags=["-r8"]

which could result in trouble, if used outside of the fpm ecosystem. But packages will still be able to do this using a custom build script (in a way defeating one of the purposes of fpm).

(Specifically, for the implicit real kind, the right thing to do would be to push for a standard way to choose the default precision within a scoping unit, e.g. j3-fortran/fortran_proposals#78)

[ivan-pi]

A few related issues:

• Need Ability to Specify Options for Specific Files #425
• Compiler flags #50 (comment) (see third paragraph)
• Proposal: add an option to select fixed-form, make free-form the default #366 (comment) (last bullet point)

[awvwgk]

I think this is a take in the wrong direction. Enabling an option like -Wconversion-extra just to add a directive to every file where it warns sends the wrong message. In case of stdlib the build files set a lot of compiler flags and I didn't found any hint or justification why those are needed after diving through the git history and the pull request discussions. The correct step forward would be to reconsider the compiler arguments used in stdlib.

[ivan-pi]

Leaving the case of spurious conversions warnings aside, because it's a poor example which can be fixed at the project level, there have been at least two comments (coming from @certik and @milancurcic) about allowing file specific settings.

Looking at the gfortran options summary one can predict at least some of the usage (anti-)patterns where a need for file specific compiler settings might arise (either to allow non-standard dialect extensions or influence code generation).

While we should discourage such practices because they make programs less portable and complicate the build process, I don't think we should explicitly forbid them.

This leaves open the question, whether comment-based directives are viable as a file-specific alternative to 1) specifying settings in the manifest, or 2) relying upon a custom build script, where package developers can do what they want.