- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
devenv area.sln /build Debug
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can't help thinking therefore that there is an unresolved problem in the way the Intel compiler handles dependencies under these circumstances.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It depends on what other options you have specified on the command line devenv
/rebuild
/build

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page