v0.8.x fails to build projects that could be built with v.7.0

[HugoMVale]

Description

Projects like this one can be built with v.07.2, but not with 0.8.x. I can't say if this problem has been fixed in v.0.9.0 because this version is not yet available in MSYS2.

I am uncertain about the origin of the problem, but the error message suggests that fpm is adding flags -fimplicit-none -Werror=implicit-interface -ffree-form -J in a untransparent manner.

In the example below, I've added the flag -O just to bypass the default profile and be able to see which other flags were being added.

The build fails equally with fpm build.

(fortran) C:\Code\test-odepack\odepack>fpm --version
Version:     0.8.2, alpha
Program:     fpm(1)
Description: A Fortran package manager and build system
Home Page:   https://github.com/fortran-lang/fpm
License:     MIT
OS Type:     Windows

(fortran) C:\Code\test-odepack\odepack>gfortran --version
GNU Fortran (Rev7, Built by MSYS2 project) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


(fortran) C:\Code\test-odepack\odepack>fpm build -flag "-O" --verbose
 <INFO> BUILD_NAME: build\gfortran
 <INFO> COMPILER:  gfortran
 <INFO> C COMPILER:  gcc
 <INFO> CXX COMPILER: g++
 <INFO> COMPILER OPTIONS:   -O
 <INFO> C COMPILER OPTIONS:
 <INFO> CXX COMPILER OPTIONS:
 <INFO> LINKER OPTIONS:
 <INFO> INCLUDE DIRECTORIES:  []
 + mkdir build\gfortran_1B7CBBF3E0F91C7C
 + mkdir build\gfortran_E46CF8C2C866941E
[  0%]             odepack_common.f90
 + mkdir build\gfortran_E46CF8C2C866941E\odepack\
[  0%]                        dcopy.f
 + gfortran -c .\.\src\odepack_common.f90   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J build\gfortran_E46CF8C2C866941E -Ibuild\gfortran_E46CF8C2C866941E -o build\gfortran_E46CF8C2C866941E\odepack\src_odepack_common.f90.o
[  0%]                       dgbtf2.f
 + gfortran -c .\.\src\lapack\dcopy.f   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J build\gfortran_E46CF8C2C866941E -Ibuild\gfortran_E46CF8C2C866941E -o build\gfortran_E46CF8C2C866941E\odepack\src_lapack_dcopy.f.o
 + gfortran -c .\.\src\lapack\dgbtf2.f   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J build\gfortran_E46CF8C2C866941E -Ibuild\gfortran_E46CF8C2C866941E -o build\gfortran_E46CF8C2C866941E\odepack\src_lapack_dgbtf2.f.o
[  0%]                 odepack_sub2.f
 + gfortran -c .\.\src\odepack_sub2.f   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J build\gfortran_E46CF8C2C866941E -Ibuild\gfortran_E46CF8C2C866941E -o build\gfortran_E46CF8C2C866941E\odepack\src_odepack_sub2.f.o
[  0%]                       dgbtrs.f
 + gfortran -c .\.\src\lapack\dgbtrs.f   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J build\gfortran_E46CF8C2C866941E -Ibuild\gfortran_E46CF8C2C866941E -o build\gfortran_E46CF8C2C866941E\odepack\src_lapack_dgbtrs.f.o
[  0%]                       dgbtrf.f
 + gfortran -c .\.\src\lapack\dgbtrf.f   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J build\gfortran_E46CF8C2C866941E -Ibuild\gfortran_E46CF8C2C866941E -o build\gfortran_E46CF8C2C866941E\odepack\src_lapack_dgbtrf.f.o
.\.\src\odepack_sub2.f:1:2:

.\.\src\lapack\dgbtf2.f:1:2:
    1 | *DECK XERRWD

      |  1
    1 | *> \brief \b DGBTF2 computes the LU factorization of a general band matrix using the unblocked version of the algorithm.
Error: Invalid character in name at (1)
      |  1

Expected Behaviour

• It should build as previous versions.
• It should not add flags "behind the back".

Version of fpm

v0.8.x

Platform and Architecture

Windows

Additional Information

No response

[perazz]

As of 0.8.0, implicit typing is deprecated by default and needs to turned back on in the manifest.
See relevant discussion at #577 and #864, and an example on how to update the fpm.toml manifest at fortran-lang/fftpack#39

[HugoMVale]

Ok, but there is subtlety here...

My project project is in modern Fortran and I am totally fine with the default flags. However, one of my dependencies is ODEPACK (the example mentioned above), which is in fixed format and probably also has implicit interfaces. So, I am kind of stuck:

• I have no control over the manifest of the dependency.
• I can't (and don't want to) set implicit-typing = true, implicit-external = true, source-form = "fixed" for the whole project.

[perazz]

I understand @HugoMVale. Unfortunately, despite all the efforts, sometimes adding new features introduces breakages.

because the Fortran features are already applied on a dependency basis:

fpm/src/fpm.f90

Line 105 in 39fdc09

associate(features => model%packages(i)%features)

I believe your package should just work if you turn implicit typing on the dependency.

So I think what you can do is to submit a PR to your dependency to align its manifest to new fpm releases. In the meanwhile, you could download and modify it locally, and add it to your project as a path dependency

[HugoMVale]

Thanks, @perazz . I did as you suggested and was able to fix the problem (I had to reset all 3 features).

I still think, however, that there are 2 "problems":

1. There is a mismatch between the information presented under " COMPILER OPTIONS" and the flags that are actually used. IMO, either:

   1. the flags implicitly added by fpm should show up in " COMPILER OPTIONS". (I would vote for this one.)
   2. or, the label should be changed to something like " USER-DEFINED COMPILER OPTIONS".

   ...
    <INFO> COMPILER OPTIONS:   -O
   ...
    + gfortran -c .\.\src\odepack_common.f90   -O -fimplicit-none -Werror=implicit-interface -ffree-form -J ...
   

2. The normal behavior when using fpm build -flag X is that the flags considered in the default profiles are ignored. If we want to keep the profile flags, then we need to actively write fpm build --profile release/debug -flag X. So, I find it surprising (principle of least astonishment) that the "Fortran feature" flags are treated differently and remain active when one does fpm build -flag X.

[perazz]

See also #350, #899, #389 for discussions on compiler flags/profiles

[perazz]

Do you think we should close this @HugoMVale?

[HugoMVale]

@perazz : The issue in title is solved. On the other hand, I think the other 2 issues that I mentioned in my previous post (July 15th) are either real bugs or very-astonishing-features and, thus, deserve consideration. Perhaps the right thing to do is to create a new issue for that? What is your opinion?