We have a fairly complicated piece of software with thousands of files, multiple libraries/executables/build configurations (many implemented with #ifdef blocks), and a mixture of F77/F90/F2003 code (some of it 20+ years old) with hundreds of common blocks and dozens of modules. I'm trying to improve our build system on Linux. I'm using Intel Composer XE 2013 (we may be switching to 2016 soon) and GNU Make from GCC 4.4.7. I've run into a few problem that I'll list below.
1) We have a build order generator written in perl that deals with the module dependencies, but I'd like to use the ifort dependency generation to determine the build order. If I run, for example, "ifort -P -gen-dep=file.d file.F90" (along with all of our include paths, preprocessor definitions, etc.) It does generate dependency files with rules for objects, includes, etc. but it doesn't create rules for *.mod file dependencies (even if I use the -module option). If I don't use the -P option, it does generate the *.mod make rules, but usually bombs during compilation because it can't find *.mod. Is there a way to generate module dependency rules with ifort without actually compiling?
2) When generating dependency Make rules for #include files and *.mod files, the targets of the rules do not have absolute paths, which breaks Make's dependency trees. Example:
! file "BLOCK.CMN" INTEGER i COMMON / CBLOCK / i ! file file.F90 MODULE MOD_A IMPLICIT NONE INTEGER a CONTAINS SUBROUTINE set(aIN,iIN) #include "BLOCK.CMN" INTEGER, INTENT(IN) :: aIN, iIN a = aIN i = iIN END SUBROUTINE set END MODULE MOD_A
If the previous file is compiled with the command...
ifort -c -I/path/to/includes -module /path/to/mod/files -gen-dep -o /path/to/objects/file.o /path/to/source/file.F90
... it generates the following Make rules...
file.o : /path/to/includes/BLOCK.CMN mod_a.mod: /path/to/source/file.F90 /path/to/objects/file.o : /path/to/source/file.F90
... instead of ...
/path/to/objects/file.o : /path/to/includes/BLOCK.CMN /path/to/mod/files/file.mod : /path/to/source/file.F90 /path/to/objects/file.o : /path/to/source/file.F90
If I understand it correctly, Make won't resolve the fact that "/path/to/objects/file.o" is the same as "file.o". The problem this causes is that you can modify "BLOCK.CMN" and nothing will get rebuilt.
I can probably provide an full working example if needed. Thanks!
1) would probably be resolved by adding -syntax-only, but I know of a bug in the version you're using where this combination results in an incorrect dependency file. This is fixed in the 2016 product.
2) Have you tried using VPATH= in your makefile?
Thanks for the reply!
Sorry, I should have mentioned that I've been testing recently with 2016. Is the bug to which you referred where 2013 creates dependencies for the temporary .i90 files? (That's why I've been testing on 2016.)
I tried -syntax-only and it did generate the *.mod Make rules, but it also generated (and looked for) *.mod files, so I ran into the same ordering issues. Another interesting thing that -syntax-only did was to change the rules that included source files to point to the preprocessor outputs instead of the source files (i.e. "file.o : file.F90" changed to "file.o : file.i90").
I did have VPATH set, but it was only pointing to my source directory. I added the include, object, and module directories to VPATH, but it didn't help.
Was this issue resolved and is a workaround available? I have the same problem using ifort 18.0.1 20171018 on Red Hat Enterprise Linux 6. The dependency files do not pre-pend the module directory location to the target. Adding "-syntax-only" to my Makefile did not resolve the issue.
This is the command I'm issuing to ifort:
ifort -gen-dep=solver/mod_version.d -i8 -r8 -std08 -fpp -diag-disable=5268 -g -free -I. -Isolver -c -o solver/mod_version.o solver/mod_version.f90 -module solver
And this is the dependency file that is generated (solver/mod_version.d)
mod_version.o: ./version.h mod_version.mod : \ solver/mod_version.f90 solver/mod_version.o : \ solver/mod_version.f90
I'm expecting "solver/" to be in front of the mod_version.o and mod_version.mod targets.