AAA Recompiling already compiled files

AAA Recompiling already compiled files

Hello,

I keep having problems with files recompiling although they just have been compiled.
For some projects I have to build the project several times before recompiling stops.
It didn't bother me very much before, but as projects are getting bigger the problem is getting more annoying.
It seems to happen mainly with programs that make extensive use of modules (although I am not really sure that that's the reason).
I first guessed that it had to do with circular references between modules, but I cannot find such a situation. The compiler/linker will probably detect such situations anyway doesn't it?
I guess it is a Microsoft Developer Studio problem. The same problem appears if I build these projects on other computers with CVF installed.
Has anyone else seen this problem? Is there a solution?

Thanks,

Walter Kramer

23 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

Hi Walter,

Your subject line had me rolling! :) The Yellow Pages would be proud. &ltvbg&gt

If your problem is DevStudio related (dialog saying that the project should be rebuilt even though you just did), this has almost always worked for me: close workspace, delete .opt and .ncb files and re-open workspace. The files will be re-generated.

hth,
John

Thank you John,

Deleting the .opt file seems to work, but what is an .ncb file?

Adding the "AAA " to the subject line was obviously intended to ridicule the sorting method of the new forum. At this moment there are only 21 messages, so it is still possible to look for new ones, but this could change.
Although who's gonna post a question that nobody is ever gonna find?

Walter Kramer

This is one of those places where a reply-to-a-reply is a nice feature.

If you don't have VC++ installed, you probably don't get the .ncb.
Here's a description of MSVC++ file types in the VC++ Users Guide

-John

Deleting .opt and .ncb files and rebuilding the project does not help always. The problem seems have to do with time stamp of the object and source files: Every time you try to run your program from within Dev.Studio, it seems to compare the times when object and source files were created. And if you have just modified your source files AND if you have the source files somewhere far in the network or in some Source Safe data base, then it happens often that the object files are built and saved before the source files (or some of them) got to saved at their place far away when you run "Rebuild". Thus the source files are newer than object files again!

I don't know how to solve this.

BTW, I posted a message on Nov. 28 (Porting from VMS) but it never appeared on the board.

Regards,
Sabalan.

Hi,

A same kind of problem occurs with the Textpad text editor textpad .
After saving a file keeping the file open, switching to another application and returning to textpad you get a message that another application has updated the file, although this isn't true. It seems to have something to do with the windows cache and the timestamp. The textpad people haven't been able to solve the problem also.
Deleting the .opt file helped me yesterday, but today the problem reoccured, and I couldn't solve it by deleting the .opt file.

Walter Kramer

If the theory in my precious posting is right, then doing the job ?manually? should help: ?Save all? your source files first (e.g. clicking on the button with several floppies), give the computer (and the network) some second to complete the saving process, and then run ?Build? or ?Rebuild all?.

Sabalan.

I am afraid that nothing really seems to help.
Deleting the opt file helps sometimes.
Saving all files and waiting a while before a "build" or "rebuild all" causes of course a re building of all files, but if I try to "run" the program a dialog asks if I want to rebuild (without a reason as far as I know).

Sometimes the re building even starts automatically after a build has just finished, as if something has changed in the mean time (which is obviously not the case).
I have tried it on a stand alone machine with Windows 98 and in a network environment under TN. That makes no difference.

Am I right to assume that the compiler/linker checks for circular references in modules?
I am pretty sure that this is not the case in my projects, but if the compiler/linker checks it I can be certain.

Walter Kramer

Hello,

If someone wanders what means in my previous posting to this thread:
I used "Spell Check" after composing this message.

The spelling checker changed 
to .

You can press "edit" after you used the spelling checker, which gives you the impression that you can still modify things, but that is just to keep you busy.

Walter

Hi Walter,

Yes, that problem exists, (don't know if they fixed it in CVF 6.5). The problem is that source files are dependent from Debug*.mod files and such dependencies are not handled correctly (I don't know whether it is a bug in Developer Studio or Compaq's implementation). If your project consists _only_ of MODULEs, that can be a huge problem. I have a large project with about 20 MODULE files, while the other 80 contain just routines. When it is necessary to rebuild all (or make a change in a high-ranked solution) I use the following half-solution:

1. Build/Update all dependencies

2. Build the project. When all MODULEs are done, i.e. when it gets to the
first non-MODULE source, break the compiling (ctrl+break)

3. Repeat step 2 until it does not compile MODULE files anymore. Let the
compiler finish the job.

4. The linker will complain about the source file where compilation was interrupted. Re-compile that file (right-click in FileView/Compile)

5. Repeat (4) until the linker finishes the job.

HTH

Jugoslav

Jugoslav
www.xeffort.com

Hi Jugoslav,

The method you describe works rather well for projects with only limited use of modules.

However, since using modules can help you considerably in structurizing your projects, I started reorganizing some major programs a while ago making extensive use of modules.
I love the use of private, public, only and alias capabilities of modules, and the reduction in interface sections.
Now it seems that my enthusiasme for the use of modules has saddled me up with another problem.
I have upgraded to CVF 6.5, but the problem remains.
I think that it is a DevStudio related problem anyway. I assume that keeping track of changes to source code, modules libraries and or object files is a DevStudio task.
I don't find any information on this subject in the Microsoft Newsgroups or on their web site though.

I guess I just will have to learn to live with the problem and try to stay of the modules in the future if possible.

Thanks Walter

Yes - all of the dependency tracking is handled by Microsoft components of Developer Studio that we can't modify. It seems that people tend to have this problem more often if sources are kept on a remote server. But sometimes there's something we can do, so please send a sample workspace, if all the files are local, to us at vf-support@compaq.com and we'll take a look.

Steve

Steve - Intel Developer Support

I am afraid I am not allowed to send any of the workspaces I was talking about (These projects do have all the files local).

I will try to create something as simple as possible that shows the problem and send it to vf-support.

Walter Kramer

Walter,

I believe I encountered the same problem today, after adding a couple more modules to a project under construction. "Rebuild all" would run to completion. Then, when I tried to run the program from the debugger, I got the message

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

These files need to be built:

etc.

Would you like to build them?

I chose Yes. The program then rebuilt and ran. I immediately chose the normal exit from the program and tried to run it again. The same message came up.

I discovered I had a module in one file that USEd a module in another file. A subroutine in the second file used the module in the first file. I then created a new file called LowLevelModules.f90 and moved to it all of the modules that did not reference any other modules.

End of problem!

Dick,

I don't have any multi-module files. Every module is in a seperate file.
So I am afraid your solution won't work for me. Thanks anyway.
I did send a project that has this problem to CVF-support. Hopefully they can come up with a solution.

Walter Kramer

Walter,

You don't have to have multi-module files. Here's a short example of a console program that does not have circular references between modules but does have circular references between files:

File One

  
PROGRAM TestRecompile  
  USE MOD1  
  IMPLICIT NONE  
  CALL SUB2  
  CALL SUB1  
END PROGRAM TestRecompile  

File Two

  
MODULE MOD1  
  TYPE T1  
    INTEGER :: M1  
    REAL :: X1  
  END TYPE T1  
END MODULE MOD1  
  
SUBROUTINE SUB1  
  USE MOD2  
  IMPLICIT NONE  
  PRINT*, UT1  
  PRINT*, M2  
END SUBROUTINE SUB1  

File Three

  
MODULE MOD2  
  USE MOD1  
  TYPE (T1) :: UT1  
  INTEGER :: M2  
END MODULE MOD2  
  
SUBROUTINE SUB2  
  USE MOD2  
  IMPLICIT NONE  
  M2 = 3  
  UT1%M1 = 4  
  UT1%X1 = 1.7  
END SUBROUTINE SUB2  

Dick
(IE5/WinNT, msg. prepared with formatting codes)

Hello Dick,

This could very well be the problem I face with some of my projects. I will start scrutinizing then for the appearance of the phenomenon you describe. Thanks.

On the other hand the following simple console application also doesn't seem to be able to keep track of file dates:

File one

 
module el_1
integer,parameter::u1rb=2
real*4 :: ra1(u1rb)
contains
subroutine p1(i)
integer, intent(in) :: i
if (i.le.u1rb) then
ra1(i)= 10.
endif
end subroutine
end module

File two

 
use el_1
call p1(1)
end

The first build goes OK, but forcing a rebuild of file one, for instance by adding a character and removing it again, then press F7 to build followed by F5 to run will result in a polite request to rebuild the project.
(try several times because it sometimes goes OK for no obvious reason)

When changes are made to file two this problem won't occur.

I also noticed that forcing a rebuild by explicitly saving file one doesn't trigger the problem.

Seeing the number of suggestions that have been made regarding the cause of this problem, it seems that Developer Studio is just not equiped very well to deal with modules.

I hope update 6.5a arrives quickly so I can switch to the faster module compilation CVF 6.5 has to offer. This recompilation thing gets very annoying especially if you combine windows programs with lots of modules.

Thanks

Walter

I apologize, the last example I posted to this thread could have been solved using the method described by Sabalan earlier in this thread. I.e. saving the source files "manually" before building the project. The same goes for the example posted by Dick.

It seems that leaving the responsebility for saving modified source files to Developer Studio is not a good thing to do (at least not when you do use modules in your project)

By the way, I am a bit curious how it is possible that Dick's example can be build anyway?

Doesn't recompiling of a source file that contains a module also causes updating of the *.mod file and thus cause the need for recompiling of all sources that depend on this *.mod file?

Walter Kramer

Walter,
I should have mentioned earlier that I have CVF 6.5 running on WinNT.
Perhaps because of that, my experience differs from yours in two ways. 1) After more than twenty attempts, I have not had any problem at all with your example, and 2) Sabalan's method doesn't solve the problem with my example. I think you're right to wonder how mine can build at all; in fact, Rebuild All always results in eight errors.
Dick

I have come into this conversation rather late, but let me say that I see exactly these problems also. We are developing/rewriting a program which has on the order of 300 files. Most every file has 1 module per file, and that is it. A small number of files have one subroutine per file. I have been living with this behavior since the 5.0D days (3-4 years ago) and am now at 6.5. I see four kinds of behavior:

a) the compile will fail because it can't resolve a USE dependency because the USE'd module has not yet been built (even though we hit "Update all dependencies" before starting the compile). Sometimes, I can hit the Build button again, and it compiles to the end, other times, I pretty much have to compile the offending uncompiled module manually, hit build again, and all goes fine.

b) the code compiles all the way to the end, links the objects, then goes off and recompiles more modules and subroutines

c) when I hit the Debug button, DevStudio asks if I want to recompile. This is not all that troubling to me since it is not a real timewaster - I just hit "No" - I am smarter than the software :-). It used to be in previous versions that this would happen more often to me when step (b) would occur. This would of course make sense because if some modules are recompiled after the link step, DevStudio should think the code needs to be rebuilt. But lately, (since v. 6.1a) symptom (b) does not happen all that often, but I will still get this message pretty regularly. More often than not, symptom (a) is the offending annoyance at this point in time.

d) I hit "Build" the DevStudio goes off recompiling a whole lot of Modules that it seems like it probably does not need to. I rely more on gut intuition here than anything else. This is hard to diagnose since the USE dependencies are so complex in our code, and it may not be entirely obvious that one Module does in fact need to be compiled, because it USE's a module that USE's the actual module that was modified.

I do not waste my time doing successive recompiles in an attempt to minimize such behavior. While this may help in some instances, I have found it to be sufficiently sporadic that I would end up spending more time compiling my code than doing actual development. So I just let CVF do its thing, hit the "No" button or "Build" button when I have to, and upgrade my hardware when necessary to in an attempt to speed up the compile stage, thus making these issues less of a time waster. What a difference it made going from a 266 Mhz PII to a dual Pentium 850 Mhz PIII. My productivity went up 20-fold.

To answer Walter's question since no one else has explicitly done so - the dependency checker does check for circular references, at any level, so you need not worry about that. If there is, the build stage will fail.

Hope that helps contribute something to thread,
Chris

Dick, I have tested with 6.5 under Win98 and 6.1a under WinNT. both gave the problem. I haven't got the possibility to test 6.5 with WinNT at this moment. So that is possibly the cause that your results differ from mine.
I used Sabalans method in the sence that I saved the changed file manually and then gave a build command (F7) followed by a run (F5) command. I didn't give a rebuild all.

Chris, the situations you describe are exactly what I am facing. Your solution seems to be a bit fatalistic though. I prefer that something will be done to solve the problem although this could possibly be classified as fighting against windmills. I am well aware that a solution has to be offered by Microsoft, but I bought a Compaq product so I aim my questions at their support departement and this forum.

Walter Kramer

Just to remind folks - this forum is NOT a "support" channel, in that if you want to ask for support from Compaq, you need to write to vf-support@compaq.com While some Compaq engineers participate here, this is meant to be a user-to-user information exchange.

If you're having problems with the dependency checker, please send a ZIP file of your workspace to vf-support@compaq.com, along with a problem description, and we'll be glad to look at it.

Steve

Steve - Intel Developer Support

The following section from the release notes for CVF 6.5a is on this subject

It works the same as "manually" saving the files, but releases you from the "manually" part.

If the files created during a build appear to be out of date, and you are running Visual Fortran on Windows 95 or Windows 98 operating systems, there is a possibility that the timestamps on the files created during a build can be off by up to 2 seconds. With faster machines and performance improvements in the linker, this can cause the .OBJ files to have a later timestamp than the result of the linker. This makes some projects appear out-of-date after a build and thus Visual Fortran may incorrectly indicate that another link is needed. If you encounter this problem, you can work around it by adding a pre-link build rule to your project that takes 2 seconds or longer. Executing a console application that does a "CALL SLEEP(2)" will work fine.

Walter Kramer

p.s. I only experimented with it under Win98

发表评论

登录添加评论。还不是成员?立即加入