Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646

Dependency Generation Issues

Sean_B_2
Beginner
267 Views

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!

0 Kudos
6 Replies
Steven_L_Intel1
Employee
267 Views

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?

Sean_B_2
Beginner
267 Views

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.

Steven_L_Intel1
Employee
267 Views

I think at this point it would be helpful to have a small test case that shows the various issues.

Sean_B_2
Beginner
267 Views

Here's a .zip file with some examples.  The test1.sh and test2.sh correspond to list points 1) and 2) from the first post.

Steven_L_Intel1
Employee
267 Views

Thanks for the examples. I agree something seems off here. We'll take a closer look.

palles__michael
Beginner
267 Views

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.

Reply