-
Notifications
You must be signed in to change notification settings - Fork 111
Open
Labels
mediumDifficulty level is mediumDifficulty level is medium
Description
fpm currently has limited support for source file includes which I notice are used a lot in existing packages and are fundamental to c
libraries. Specifically:
- fpm cannot yet track module dependencies in included files;
- fpm incremental rebuilds do not track changes in included files and;
- included file cannot have the
.f90
suffix
I am currently working on an update to fpm to address these shortcomings.
vmagnin, jbdv-no and beddalumiazoziha
Metadata
Metadata
Assignees
Labels
mediumDifficulty level is mediumDifficulty level is medium
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
jbdv-no commentedon Mar 3, 2021
While trying to use fpm (incredible effort by all the developers btw, thank you!) in one of my
projects, I have encountered a problem when using
include
statements with the nagfor compiler.Nagfor fails to compile since it cannot locate include files (named
*.inc
, located along withall other
*.f90
source files in the./src
directory). The very same directory structure worksas expected when using gfortran or ifort to compile.
Searching through fpm's documentation and issues for a solution, lead me to this particular issue,
and since I could not find particular mention being made of nagfor in this context before, thought
it could be useful to share this very simple reproducer. (Assuming of course that I am using fpm as
intended, very possible that a naming/other mistake on my side is causing the trouble)
Reproducing the problem
Create a new fpm project:
Put the subroutine
say_hello
fromsrc/fpm_inc.f90
into a separate filesrc/say_hello.inc
and modifysrc/fpm_inc.f90
toinclude
this file:This project builds successfully with gfortran (default) and ifort:
However, it fails with nagfor, which complains that it cannot open the include file
In this trivial case, the
include
is easy to avoid. However, in my actual use case the includefile implements an algorithm using kind specifiers inherited from the module scope (so a form of
"poor man's templates"), with different modules defined for different kinds.
According to nagfor's documentation:
Which would imply that an additional
-I ./src
can solve the problem in this particular case? Butthis is surely not the general solution.
PS: You may notice from the code snippet, that I built fpm from source (using a binary release)
and removed
-coarray=single
from the compiler flags. Since this is a feature (introduced inrelease 7.0) not supported by the release of nagfor that I have access to (Release 6.2).
LKedward commentedon Mar 3, 2021
Many thanks for the detailed report @jbdv-no, it looks like
nagfor
behaves slightly differently togfortran
andifort
which first search in the directory of the current source file. The solution for this issue will make the include directory explicit and so should fix your issue also.