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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
See /usr/share/doc/debhelper/PROGRAMMING.md on general design of debhelper.
This follows that design.
For convenience of Python code, dhfortran/debhelper.py implements Python equivalents of any Perl debhelper routines we use.
The scripts are written in Python for ease of development and testing. The package provides:
* dh_fortran_mod: Move Fortran-module files to per-compiler directories
* dh_fortan_lib: Ditto for libraries, but also change SONAMES
* dh_fortran_pkgconf: rewrite pkgconfig files to match the above
* dh_fortran: overall builder script
See manual pages for each.
TODO:
* What if buildsystem == meson, cmake, ecbuild ?
--buildsystem=fortran means using fpm.
automatically enables --with fortran
--with fortran will use fpm if buildsystem is not set.
* dh_fortran_lib:
Install ar archives correctly with multifortran, keep_orig
* For 0.65 release:
_lib,_pkg,_cmake,_mod scripts have --buildsystem mode where they run without config file
Targets are called with FC, FCFLAGS, FMODDIR, FC_DEFAULT, FLIBDIR set as appropriate
Set 0.80 release as having full multifortran and cross-compilation support
* With fpm 0.13+ for multiple builddirs; meson overrides
Set 1.0 as release to remove --flavor flags. Full deprecation warnings in 0.80
FPM Integration:
* dh-fortran executes fpm where fpm.toml is present and buildsystem=fortran
* check fortran-fpm in environment
* fpm search plugin for Apt/dpkg integration (?)
fpm will use / install modules if they exist in Debian; alert missing modules
-DONE
Multicompiler builds will be triggered by:
* Presence of FC_DEFAULT, FC_OPTIONAL in the environment
* presence of *.fortran-mod or *fortran-lib files in debian
ISSUES:
* fpm only works with one builddirectory ./build
This will be fixed in the next release
--with=fortran needs to add most of the work (inject something into d/rules)
because --buildsystem may point to eg ecbuild,meson
Multi-fortran decision process:
* DO a make -P | grep FC_DEFAULT, FC_OPTIONAL check. If they're defined in d/rules, then thats what sets their values
store flags env in .debhelper/fc_env. len(FC_OPTIONAL)>=1 means multifortran build
* For the moment, FC_DEFAULT allows a single flavor
* Set BUILDDIR. TMPDIR. Will need a different TMPDIR for each of the other Fortran builds.
* for FC_DEFAULT, BUILDDIR=$(BUILDDIR), for all compilers define $(BUILDDIR)-$(FLAVOR) and for default its a symlink to $(BUILDDIR)
* ditto $TMPDIR.
*
dh_assistant which-build-system
{
"build-directory": "obj-aarch64-linux-gnu",
"build-system": "cmake+makefile",
"buildpath": "obj-aarch64-linux-gnu",
"dest-directory": null,
"for-build-step": "configure",
"parallel": 1,
"source-directory": ".",
"upstream-arguments": []
}
Pick build-directory, dest-directory from dh_assistant or equiv.
Check dh-fortrans' use of source,dest etc terms correct.
* Allow FC= to be a cross-compiler, deprecate --flavor in favour of use --fc and accept aliases, but use flavor internally
for the "canonical"
Notes:
Dropped get_flavor(), get_fc() in favour of get_fc_flavor() which does all checking.
Use FC as the external API, flavor as Internal, but we should track the FC for cross-compiling:
when --fc = other-arch-gfortran-15 , flavor=gfortran-15, but we've lost the arch.
How about flavor, arch = get_fc_flavor_arch() ?
Issue: what if binaries in a package use the pre-adjusted sonames?
Best if we can set the SONAME pattern at build-time
FPM Integration
export FPM_FFLAGS="-I/usr/lib/aarch64-linux-gnu/fortran/gfortran-mod-16/ -I/usr/include -cpp"
TODO:
* Set --builddirectory=debian/build-$$f in fortran.pm
|
