Always recompiles

[tmcole]

Well, I'm certainly getting my monies worth from this forum. I now have a problem with the CVF environment always forcing a recompile of every file in the project, regardless of whether I have changed anything or not. In fact, when I build the project completely and then press the "Start" button in the debugger immediately after the project finishes building, I get the following:

One or more files are out of date or do not exist

These files need to be built:
.Debugdialog.exe
.DebugMSCLIB.MOD
.DebugTVDC.mod

Would you like to build them?

Obviously, nothing has changed to cause the issuance of this message. I thought that maybe something is corrupted, so I started a whole new project in a different directory and then copied over the following files:

w2.f90
screen_output.f90
resource.h
resource.fd
w2.ico
w2.rc
w2.aps

I seem to remember this problem popping up periodically in this forum, but the one thing I have found is to "update all dependencies". This does not work. Not only that, but after the update of all dependencies one of the edit box parameters that caused a problem (I called it cpu_time which conflicted with an intrinsic function of the same name) will not go away even though I have renamed the edit box to cpu_times and deleted it from the resource.h and resource.fd files. I cannot make this error go away although there is absolutely NO reference to it anymore in any of the files. Any thoughts?

[Jugoslav_Dujic]

Check out your system date/time, as well as source file timestamps. Dependency analyser offers recompiling if .obj file is older than its source file. If someone has messed up with system time or source times, that condition is never satisfied.

Jugoslav

[Steven_L_Intel1]

Try doing a Build..Clean and then Build..Update all dependencies and see if that helps.

Steve

[tmcole]

It doesn't have anything to do with the computer. I have copied the project directory to my XP and laptop and have the same problem with both of these machines, where previously I did not. Something is screwed up in the dependencies. I would have thought that creating a new workspace, copying over the relevant files (source code, header, and resource files), and doing a new build would have rectified this problem, but obviously not.

Since both w2.f90 and screen_output.f90 (the only two source files in the project) are always recompiled, it appears that either a module or include file common to both of the files would have to be the culprit as it is now 11:21 am and the timestamp on the w2.f90 code is 7:56 am. Doing a "clean" and "rebuild...all dependencies" is no help. Again, what is really weird is that if I build the exectutable and then try to execute it, I get the aforementioned CVF message. However, if I click on execute or debug, then the program compiles and executes without wanting to recompile. But if I quit and immediately run the program again, CVF wants to recompile. Any other suggestions?

[pcurtis]

CVF has been plagued by the "compilation cascade" problem since v5.0. In numerous discussion threads in this forum, the c.l.f. newsgroup, as well as in private correspondance, Compaq (now Intel) has grudgingly acknowledged the problem, but it has always been blamed on the dependency checker supplied by Microsoft as part of DevStudio, over which Compaq/Intel has no control and hence cannot effect any progress.
The problem is not confined to CVF, and is evidently addressed in other Fortran development environments by clever makefiles which game the system and prevent unnecessary compilations with each build; there was an article on this in the Fortran Forum newsletter within the past 18 months.
I introduced this topic again, as a question, within a recent thread here on the anticipated benefits of the forthcoming "IVF" grand convergence product, and Steve stated explicitly that this problem has now been solved completely since the dependency checker for the new IVF development environment is now done by Intel. Steve is welcome to (re)confirm this statement.
Until this is proved to be the case, there seems nothing we can do to improve matters.

[tmcole]

Well, I solved it and its very interesting (at least to me). I had all my modules at the beginning of the main program including the one called MSCLIB that Jugoslav so kindly provided me with. The other file in the project deals exclusively with CVF related code. The code has to be able to run on a variety of different computer platforms (I am currently developing a version of it that will work on a number of different massively parallel codes we have here at the research station), so I try to keep all compiler specific code together and use a preprocessor to spit out platform specific code. This allows me to maintain a master version of the code, rather than a gillion different versions of it that I would have to ensure all changes to the core of the code were propogated correctly through the different versions.

Anyways, to make a long story short, I moved the MSCLIB module over to the screen output code. Apparently, this caused a disconnect between the two code sections when compiled resulting in the original problem. When I moved the MSCLIB module back to the main code with the other modules, the dependency problem disappeared.

I can't decide if this is a problem that should exist, or if the dependency analyzer is poorly written and there should be an elegant solution to the problem. Anyways, I wanted to post the solution in case anyone else ran into this problem. Also, it would be nice to have this limitation documented somewhere.

[Steven_L_Intel1]

The MS part of the CVF dependency analyzer throws up its hands when it thinks there are three or more levels of nested dependencies, the symptom being "recompile everything". Fixed in Intel Fortran 7.0 and later.

Steve

[tmcole]

Steve, I'm probably confused with what you mean by nested dependencies, but, according to my understanding, there should only be one level of dependency. There are no modules within modules. All programs, subroutines, and functions call the individual modules as needed.

What I did is the equivalent of taking one long piece of code that contained all the modules, program, subroutines and functions and breaking it into two pieces of code with all modules defined in one of the pieces, except for the MSCLIB module. I did this becuase the only thing I was changing was CVF specific code and I wanted to speed up compilation times during development.

So, I don't see how the problem relates to nested modules. What am I missing here?

[Steven_L_Intel1]

Don't know - I don't pretend to understand the problem in detail. I just know it was too easy to get the MS code confused.

Steve