# DH_FORTRAN: Fortran support for Debian packaging

NOTE: 

This are notes on multiple Fortran support , a nascent Fortran policy

Background:

 After years with just one Fortran compiler, Trixie may potentially ship with four:
 gfortran, flang, flang-to an external fc, lfortran (coming)

 There is a surge of interest in Fortran and new Fortran compilers for performance and new hardware.
 This renaissance mostly does not involve new Fortran applications, but optimising existing libraries
 to work on new architectures and using new compiler technologies - e.g. LLVM - for optimisation.
 It also includes using Fortran as a low-level language for other frameworks and autogenerated
 Fortran and using source-to-source tools such as Psyclone.

 This requires us to 


* gfortran is the  default compiler
* At minimum, each package supporting or using Fortran should build-depend on: gfortran | fortran-compiler
  It is possible to build-depend on `dh-fortran >= 31` which will pull in the default compiler.

* Each fortran  library package will build on the default compiler and optionally other compilers

* It should be possible to recompile a package / stack of Fortran libraries simply by:
   FC=newcompiler dpkg-buildpackage
  If this is done, the `newcompiler` will be the default compiler
   
* There are 2 alternatives defined: f77 and f95. Again if installed these should override the default Fortran compiler in the debian/rules


Module (and submodule) files

There are then multiple "module" or pre-compiled header formats. These typically end in .mod or .smod but may be 
non-compatible between compilers and compiler versions. Hence to enable multiple compilers to be present, module files
from different compilers need to be in 
These are installed into a directory called $(FMODDIR).

Library ABI and linking

Librariess that are compiled by an external Fortran library will be able to link against other objects compiled by that library.
So code compiled by eg 'flang-to-ext-fc', where the external FC is gfortran will be able to link against code  compiled by that
library or gfortran, but presumably the 'flang-to-ext-fc' should be faster (which is why its being done).
So we expect to ship 'flangext' variants of libraries but create a library load path that looks like:
  $(LIBDIR)/fortran/flangext:$(LIBDIR)/fortran/gfortran

TODO: Corner cases:
* FC is external, full-path or short-path
* Submodules

NOTE: This is likely to be rewritten with complex functionality in Python


CROSS-COMPILING:

Either:
 (a) dh-fortran depends on 'gfortran-for-host | fortran-compiler', making it Arch: any, MA: foreign or drop Fortran dep
    following discussion with Helmut
    Drop gfortran deps from most Fortran packages
