Build and Rebuild always do a build all

[Intel_C_Intel]

Hello,

I have recently migrated from CVF6 to IVF9 and am taking some time getting used to the new environment.

One thing that I have noticed and is driving me crazy is that every time i choose the build or rebuild option it recompiles and links all fortran code in the project. I have tried both the top level right click from the solution explorer, the right click project only submenu, and the main build menu options.

This is with "stand alone" projects in the solution. If I make them dependent on each other they rebuild all the dependents before rebuilding all of itself.

I've posted before with a mis-set configuration item, so I'm sure this is something similar, as this cannot be the designed action.

At the moment this is just irritating - once I migrate our main development it will become impossible.

Any pointers on what I need to change would be greatly appreciated.

dajm

[Steven_L_Intel1]

Are your sources or objects on a local disk or a network share? Sometimes the latter can cause timestamp skew problems. Does a Build..Clean help?

[Intel_C_Intel]

Hi Steve,

All files are on a local disk.

build then Clean does a rebuild all, but I would expect that as the intermediates are being removed.

A build, clean, build,modify, build also does a full rebuild.

I have never seen the fortran compiler say 0 to build, all up to date.

dajm

[Steven_L_Intel1]

I would ask that you submit a ZIP of your entire "solution" to Intel Premier Support so that we can take a look. Before doing that, though, please make sure you are running the latest compiler and integration, 9.0.024.

[Intel_C_Intel]

is there an easy way to get the version number?

I ask because Help/About gives version 9.0.2713.2003 which implies its more up to date than yours.

Running ifort.exe from the IA32 folder gives a version of 9.0 but a z package id of 9.0.017.

If this is the case I'll download the latest and try that before submitting.

dajm

[Steven_L_Intel1]

Perhaps the simplest way is to open C:Program FilesIntelCompilerFortran9.0DocsNotesfsupport.txt This is also shown when you start a "Build Environment for IA-32 Applications" command prompt.

9.0.017 is the original release. Please download and install 9.0.024.

[jim_dempsey]

Two situations come to mind:

a) Explicit circular dependency list (check your dependencies)

b) Implicit circular dependency (non-obvious gotcha)

At times a solution is constructed whereby an innocous "source file" is created versus and object file. For me this often happens to be a resource header file created for a dialog box. To correct this you should try to isolate the dialog boxby placing it into a seperate project and then placing that project early in the dependency list.

Unfortunately there isn't a /TellMeWhy option to indicate what dependency caused the recompilation. This would be a nice optionto have.

Jim Dempsey

[Intel_C_Intel]

Thanks for your input Jim.

I have to say that I hadn't considered that specific type of interaction, but its not possible (not as far as I'm aware anyway) in this case.

Following Steve's suggestion above, I downlaoded the latest version and after confirming that it was still doinga reb7uild all each time, I created a new cleaner solution to submit to premier support.

Thisnew solution consists of about 10 files, using a few includes and a couple of use statements.

All but 2 of the includes are on the standard include folder for my projects, the other 2 are in the same folder as the fortran.

With no files open I can build (which builds all), open a single file and modify it. When I choose build from the menu I expect just the single file to recompile and the project to link. However all 10 files build again.

Hopefully premier support will come back with an answer.

dajm

[jim_dempsey]

I too had a similar problem that may have been worse. Not only would Build perform a Rebuild All but a F5 to run the debugger would query with a "Some files out of date. Do you which to Rebuild?" Answering No would successfuly launch the debugger about 50% of the time. The remainder of the time I would get a "We're sorry but an applicaiton (devenv) caused ... and we will have to terminate your application". This was a real crock.

If I pushed the "We're sorry..." dialog box out of the way I could debug the program for a while up until the "We're sorry" timed out, in which case it killed the program (and my debug session) regardless of my inaction to OK the kill of my application.

There were two problems.

One was the resource file from a dialog box. Note resource.h is pushed through a converter file to produce resource.fi for a two step build. If files in the project that builds the Dialog is dependent on resource.fi then yourproject that builds the dialog bosx (and other files)has a circular dependency with itself.

The second problem (the trashing of devenv) was the application was driven off a script file (a text file). The application would open the text file for exclusive use. However the IDE would be viewing the text file. The open files in the IDE are not open as such but are briefly opened during start and saves. The remainder of the time temp files are used. When the debugger is launched with F5 the current IDE session is context saved and a new IDE (devenv) session is spawned _while_ the debugger is starting the application. In my case the program start code is debugged and my first break point was somewhere late in the program, after the point where the script file was opened. It appears that there is a critical section where the debug IDE session (re)opens the files from the context of the edit IDE that the debug IDE session encounters a file in use condition. Which in turn cause the debug IDE to access memory not allocated. This in turn caused the "We're sorry..." but otherwise did not interfere with the debug session (until it killed the program).

What fixed this problem was I now run the IDE looking at a master file (think of it as a source file) while the program runs off a copy of this file. The copy is updated as part of my build process.

This may give you some insight to the problem.

Jim Dempsey

[Paul_Curtis]

I too have noticed this behavior, which is more general than the last poster's example. I submitted this exactIssue to Premier Support way back when the current IVF version was 7.x. Premier Support did report back that the problem was verifed by them, but Ihave never had any further response towards any solution, and the problem persists through all IVF versions through 9.0.024 or whatever the most current is.

CVF had an internal dependency checker whichfigured out the correct build order for complex multi-module projects with lots of interlinking. All re-compileswouldbe limited to only those modules directlyaffected by the current (set of) changes. IVF, in contrast, seems to do no dependency checking whatever, and as the O.P. noted, always does a complete rebuild, even for the most trivialchanges to a module which USES no other modules.

In my experieice, clearing all the intermediate files and then doing a Rebuild All always fails, because IVF starts chewing through the compile list in some random (reverse-alphabetical? timestamp? as-found on disk?) order, which immediately crashes due to unsatisfied dependency. I have to figure out the correct build order manually by trial and error until all modules can finally be compiled (and my projects have 70-100 modules). This is very tedious, and, again, wasnever a problem with CVF, which always got the dependency checking and build order correct, automatically.

Steve Lionel saidinthisforum, around the time that IVF was first released, that the dependency checker used by CVF was written by MS as part of DevStudio, whereas starting with IVF the dependency checker would be supplied by Intel and under their control, and hence would perform much better making for much more efficient compiles of multi-module projects. Sadly, this has not proven to be the case.

[Steven_L_Intel1]

It is a lot better in IVF. If you have a problem, please submit a test case so that we can fix it.

[Intel_C_Intel]

Sorry it has taken so long to get back onto here, but it was quite difficult for Support to replicate the problem and I've also been away.

The problem is that I had my include folders identified with a UNC path, rather than a mapped drive. Once I swapped to mapped drives it all worked as expected.

Once it could be replicated it could be investigated. Vivek at Support has confirmed that it is a fixable bug and will be repaired for future versions.

Dermot