Circular module dependency detection

[jirina]

I suspect there is a circular module dependency in my project - if I build the solution and repeat it, compilation starts for some source code files, even though there were no changes in any any of them or anything in the solution.

My question is whether there is a way how to detect the suspected circular module dependency. I tried doing so manually by checking the source code files which are getting re-compiled, but I could not find anything.

As the compiler must know module dependency, can this information be retrieved from somewhere?

I am using oneAPI 2024.1 in Visual Studio 2022 Pro on Windows 10 Pro.

[Andreas_Z_]

Have you tried to do a complete rebuild (Build > rebuild solution) in VS? That usually gives more insights.

[jirina]

Yes, my tests followed these steps:

• Open VS, only one instance running at a time
• Open the solution
• Select configuration and rebuild the solution
• Build solution - this is where some source files get compiled again.

I further investigated the issue and it seems to be related to !dec$ if defined ( ... ) used throughout the code. To make sure module dependencies are determined correctly after the solution is opened, I would like to know whether there is any place or any tool that can be used to do such a check.

[Arjen_Markus]

This page https://fortranwiki.org/fortran/show/Build+tools may lead you the tool you need.

[mecej4]

Circular dependency/-ies is one reason for seemingly unnecessary recompilation, but there can be other reasons. For example, if you use a makefile that lists an explicit rule for producing .o files from .f90 files, but your compiler actually produces .obj files, recompilation will occur. More generally, when there are errors in dependency rules, implicit as well as explicit, recompilations will occur.

I do not know the internal details of how Visual Studio, IFX (and nmake, if that utility from Microsoft is used in the process) interact. I suspect that any preferences stored in the project file will affect how the rebuild process is performed. (Humorous aside: I typed in the phrase "IFX dependency rules" into Google, and the first suggestion was www. irs .gov!)

Here is a short example to illustrate what I said above. I have three module source files, and a program file:

S:\LANG\nagdep>type a.f90
module a_mod
   use c_mod
   integer a_i
end module

S:\LANG\nagdep>type b.f90
module b_mod
   use a_mod
   integer b_i
end module

S:\LANG\nagdep>type c.f90
module c_mod
   use b_mod
   integer c_i
end module

S:\LANG\nagdep>type pgm.f90
program tst
   use a_mod
   print *,a_i+b_i+c_i
end program

I ran @IanH 's  FF08Depends utility on these four source files, and the response:

S:\LANG>c:\LANG\UTILS\ff08depends.exe -t a.f90 b.f90 c.f90 pgm.f90
Error 8003: A cyclic dependency exists between the files "a.f90", "c.f90" and "b.f90".

There are utilities that generate a makefile after scanning a set of Fortran sources. One such utility is part of the NAG Fortran compiler, but there are free ones as well. I ran Cygwin/GNU Make on the following makefile, "pgm.mak":

FC = gfortran

%.o: %.f90
	$(FC) -c $<
pgm.exe: a.o b.o c.o
	gfortran a.o b.o c.o -o pgm.exe
a.o:	a.f90
a.o:	c_mod.mod
a_mod.mod:	a.f90 c_mod.mod
b.o:	b.f90 a_mod.mod
b_mod.mod:	b.f90 a_mod.mod
c.o:	b_mod.mod c.f90 
c_mod.mod:	c.f90 b_mod.mod
pgm.o:	pgm.f90
pgm.o:	a_mod.mod

 The result from running Make on this makefile:

S:\LANG\>make -f pgm.mak pgm.exe
make: Circular a_mod.mod <- c_mod.mod dependency dropped.