VS dependencies / Cyclic Depandancies

[andrew_4619]

I currently have  a permanently  out of date Fortran project. There is one source file, a submodule file that has only contained module subroutines and module functions. It has no dependencies on other modules  i.e. it has no USE statements. This source file always builds even after a full clean build and no changes. I may have asked this same question a long time ago  but is there any way of analysing this, for example a dependency table that VS can produce? I note VS has "Map dependencies across your solutions" functionality for C# and C++. Has anyone got any ideas what the cause might be or how to fix it?

[mecej4]

I have some tools that can perform dependency analysis, but the patient cannot be examined in absentia.

[andrew_4619]

It is not that I need to map the dependencies because there aren't any to map I just would like to understand why VS thinks that there are. I can't post the project by the way.  I suspect it is some subtle bug in the VS understanding of sub-modules. I say subtle because it seems to understand submodules OK in 99.9% of the time so if this is the problem there must be an additional factor at play. 

[jimdempseyatthecove]

Andrew,

Check your paths. You may be building new .mod and .obj files, but due to a path (including input path) the build process sees an older version.

If that doesn't fix it, I recall a decades old issue like this when the outputs are placed on an NFS share, and where the dates are not synchronized between systems. Is your output to an NFS share?

Jim Dempsey

[FortranFan]

I recommend going into a mode where you imagine briefly you have all the Fortran source code but you have lost ALL of the Visual Studio solution and project(s) files and thus you have to start afresh with VS.  So then in another folder or on another system altogether, copy over all the source code, build a new VS solution and project(s) and see if the problem reproduces.  Based on your description, chances are the problem will not recur.  You can then compare the VFPROJ file(s), the new compared to the existing one(s), and look for any settings/dependencies in your existing stuff that may be the cause of the problem.

Some problems like this have happened to me in the past and the root cause has been some hard-wired things that were silently being carried over in the Fortran project file; in one case, it was related to the fact the VS Intel Fortran project was originally created via a porting exercise from Compaq Visual Fortran (CVF) DSP project file.

[andrew_4619]

Very interesting thoughts JIm. I removed the submodule file and its parent from the project. Changed their names and changed the name of the module. Added the new files to the project and did a clean build (and checked the output folder was clean) but the problem still exists. I thus conclude it isn't your first point that is the problem. Is that a reasonable conclusion?

As to the second point the files are on a local drive but it is actively synced with a cloud drive.  I have just being looking to see if there are any sync issues that  might mess with the time stamps but I can't see that but I haven't ruled this out yet.

[andrew_4619]

@FF . A good suggestion also. I was contemplating making a new project but I hadn't considered comparing VFPROJ files that might be interesting because I hate 'fixing' problems without understanding what the problem was! I have had this type of problem before and 'fixed' it without understanding how. 

[jimdempseyatthecove]

Andrew,

I agree with FF's suggestion.

One other thing to look at is the file dates and times of the source file and generated files (all dates: Creation, Modified, (Accessed shouldn't matter), and possibly MTF last written if on NTFS).

Jim Dempsey

[Steve_Lionel]

There have been reports before of submodules confusing the dependency analyzer. FIrst thing to try is deleting the .sou file (a hidden file, so you may need to change the Explorer view to see it) and then rebuilding. If that doesn't help, zip the project and send it to Intel.

[andrew_4619]

Thanks for all the helpful suggestions the suo delete didn't fix it and a whole new solution and project didn't fix it. I can release the project to premier support so I guess I will just have to live with it until is goes away or the solution becomes apparent!

[Steve_Lionel]

Can you replace the source files with dummies (with no code in the routines) and then provide that to Intel? It's just the program unit structure that matters.

[FortranFan]

andrew_4619 wrote:

.. a whole new solution and project didn't fix it. ..

In that case, as alluded to by Steve, it suggests a bug in the VS integration provided by Intel Fortran for the situation when SUBMODULEs are involved and therefore, it will be great if you can follow up and open up an incident at the Online Service Center.  Thanks,

[andrew_4619]

UPDATE - I think a bug is the only explanation. I created sibling sub module as below:

submodule (LVIEW) LVew2  
    implicit none
    contains
end submodule lvew2

This is also always out of date along with its brother that is not empty. The parent module is not "out of date" and does not rebuild. Making a reproducer might be hard as there are many similar sub-modules in the project that work just fine, I can't see anything special about this one and indeed looking at the above there is nothing to see!

[andrew_4619]

Having lived with this problem for nearly a year, I today did a clean install for VS2017 (previously 2015)  and Compiler 2018 Upd 2 ( previously 2018 U1) and the problem has gone away. It is not clear what fixed the problem the VS or the Fortran but it is one or the other as the problem was previously evident on more than one machine.