1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
# DH_FORTRAN: Fortran support for Debian packaging
NOTE:
A
A
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
|
