On 12/12/2018 16:02, Ansgar Burchardt wrote:
On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote:
I've been looking at using the "Built-Using" tag for dh-fortran-mod.
Why not a
Fortran-Mod: gfortran-7, gfortran-8, flang-42
field or so?
As another example Python has `Python-Versi
Hello,
On Wed 12 Dec 2018 at 05:02PM +0100, Ansgar Burchardt wrote:
> On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote:
>> I've been looking at using the "Built-Using" tag for dh-fortran-mod.
>
> Why not a
>
> Fortran-Mod: gfortran-7, gfortran-8, flang-42
>
> field or so?
>
> As anot
On Wed, Dec 12, 2018 at 03:12:21PM +, Alastair McKinstry wrote:
> The difficulty here is that Policy 7.8 requires that Built-Using: is only
> used for source package tracking. This is then enforced on the upload
> package checking which rejects such packages (because gfortran-8 is not a
> sourc
On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote:
> I've been looking at using the "Built-Using" tag for dh-fortran-mod.
Why not a
Fortran-Mod: gfortran-7, gfortran-8, flang-42
field or so?
As another example Python has `Python-Version: 3.6, 3.7` (for packages
where this matters; d
Hi,
I've been looking at using the "Built-Using" tag for dh-fortran-mod.
dh-fortran-mod is a debhelper extension for handling Fortran "mod" files
(based on an original idea from Sebastian Villemont).
These mod files are effectively pre-compiled header files, in C/C++
terms; normally stored i
5 matches
Mail list logo