Build problem / Include file dependencies in .NET 2003

[a_cockburn]

We have projects containing fortran source files, have build scripts that build libraries with commands of the form
devenv area.sln /build Debug

Two consecutive builds of a solution will still re-compile most fortran files the secong time around, even though all include files and used .mod files are in past. Is there any way to display the reason why a source file is being compiled, ie which file it thinks is newer than the .obj?

More generally, does any one know how devenv (.NET 2003) keep track of source-file dependencies, or indeed if it does at all? It seems as though the compiler would have to load a source file and include files before it can decide whether or not it needs compiling; or am I completely missing the point. This severely increases build times over VS 6 for small changes.

I've also noticed that there's no longer an Export Makefile from the IDE in .NET 2003! Is there another way of creating a makefile from a solution.

Thanks in advance.

Andre

[Steven_L_Intel1]

When a project is built, Visual Studio asks the language-specific project manager to determine dependencies. This is a component we supply for Intel Fortran. You can't see it happening and there is no feedback or log available.

Does this problem occur when you build from inside the VS environment, rather than invoking devenv?

Sometimes we've seen this occur when source or target files are on a network share drive. It can also be caused by unusual settings of output files. If the problem persists with a current compiler version, please report it to Intel Premier Support and attach a ZIP of the solution with all sources needed to demonstrate the problem.

Microsoft removed the makefile export feature as of VS.NET. There are external tools available to create makefiles from Fortran sources - I have not used them.

[jcl2]

We have seen this problem too. My colleague and I have both installed IVF9.0 & Studio.net 2003, and we also end up recompiling everything in the Fortran project each time we build the solution even though no files have changed. This is with the latest 029 download. Premium Support claim they have not had any problems with this though from the posts here it seems common.

On top of that, once all is compiled, I am getting the 'cannot open IFWIN.LIB' error. If I explicitly add this to the Project page/Linker/General/Additional libraries list, it looks as if it can't find any of the Fortran functions such as _FOR_OPEN, _FOR_CLOSE etc.

[Steven_L_Intel1]

Judging from the very few complaints of this I have seen come in to Premier Support, it is not common. It does happen to some, though. Often we find that sources or the TEMP folder are on a network share and that can cause problems.

As far as not finding the library, that suggests that the paths are not properly set up under Tools..Options..Intel Fortran..Directories. This should have been done automatically.

[jcl2]

I have now managed to build the solution twice without any recompilation! All my files are located on my own machine, but in folders under c:drive_r. c:drive_r is mapped as a network drive to R:, and I normally work on R:. I redid the solution to pick all the sources up directly from c:drive_r... and not from R:... When I start DevStudio from c:drive_r... and not R:... it seems to do the trick.

I work this way because I can then keep several versions of our program simultaneously, each one thinking it is located in the root of its drive. This is a historical necessity for us, which will eventually be removed.

The notes for w_fc_c_9.0.029 appear to indicate that this issue should have been fixed, but it would seem not. Maybe the fixers did not think of testing mapped network drives?

[Steven_L_Intel1]

The release notes refer to using UNC pathnames, not mapped drives. Part of the problem is that timestamps are often out of sync for network drives.

[jcl2]

This was never a problem with CVF/DevStudio6, and is still not a problem in Studio.net 2003 for the C part of the solution. The C project behaves exactly as it should. It is only a problem for the Fortran project part of the solution.

I can't help thinking therefore that there is an unresolved problem in the way the Intel compiler handles dependencies under these circumstances.

[Les_Neilson]

Recompile UPDATE :

I am a work colleague of Andre who first posted about this recompile problem.

1. We each have the source files on local disk, not accesed across a network

2. The source files are under the control of Visual SourceSafe for checking in/outof code modifications.

3. The problem occurs both in the IDE (VS .NET 2003) and on the commandline.

4.The source files are grouped in directories which may be single source or mixed, Fortran with C/C++. The solutions in the directories build libs which are linkedwith main programs to produce executables. All fairly standard stuff.

I have just repeated the following for several directories both mixed source and Fortran only.

(A) In the IDE choose Build->Batch Build (all configurations Debug and Release etc). All the Fortran files are compiled. The C/C++ files, if any,are not compiled. At the end of each Fortranconfiguration in the build windowI get the message :

"Creating library...

Build log written to file://F:sdevscodex2dlibDebugBuildLog.htm
build succeeded."

Followed by a dialog box presumably instigated by SourceSafe with the following message :

"An editor or project is attempting to check out a file that is modified in memory, which will result in saving it. Saving files during the build process is dangerous and can result in incorrect build outputs in future. Do you want to continue with the check out?"

I clicked "cancel" each time to not check out the file(s) from SourceSafe.

Repeating the above BatchBuild the Fortran files are recompiled every time.

(B) Then on my local copies of the solution file and the "proj" files I removed the read only flag. This should stop the connection to SourceSafe even if the files are modified locally.

I repeated the BatchBuild as above. The first time was as before, the Fortran files were recompiled. But subsequent repeated Build commands didNOT produce a recompile.

I did a comparison (a "diff") between my local proj files and those in SourceSafe and there were no differences ! In fact acomparison on all files in the directory with those in SourceSafe showed no differences.

I replaced the read only flag on the files. Redid the Build command several times,and the Fortran files were NOT recompiled.

Les

[Jugoslav_Dujic]

"An editor or project is attempting to check out a file that is modified in memory, which will result in saving it. Saving files during the build process is dangerous and can result in incorrect build outputs in future. Do you want to continue with the check out?"

I clicked "cancel" each time to not check out the file(s) from SourceSafe.

Just curious -- if you click "OK", which files (if any) are checked out from VSS? (You can always investigate in VSS explorer).

[Les_Neilson]

It wants to check out the vfproj file.

Ok we think we have narrowed down the problem. Not verified as yet, but highly likely.

We recently checked out of SourceSafe all of the vfproj files, did a small change to each one, saved and checked them back in again. But we did not do a compile ofeach solution while the file was checked out.We think the vfproj file nowhas a flag set indicating a change has been made and hencearecompile is required.

Les

[Steven_L_Intel1]

Yes, it does. This is how it knows to recompile if you may have made any option changes.

[xinjian_qian]

Hi,

I used VS.net 2003 and Intel fortran 9.018 for windows. I found It will not recompile all fortran files in VS IDE after click "build" two times. but when I use devenv build, it will recompiler all files. I wonder why useing devenv it will rebuild envery time. Does the lates version fix this problem? or How can I do to let it not alwarys recompile when using devenv?

Thanks very much! It's very important for us!

David.

[Les_Neilson]

It depends on what other options you have specified on the command line devenv followed by

/rebuild will recompile every time

/build should only compile any changed files.

Les