MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009169CMakeCMakepublic2009-06-16 19:592009-09-17 15:35
ReporterKelly Thompson 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009169: CMake fails to generate Visual Studio 2008 solution when using Intel Visual Fortran 11
DescriptionWhen trying to build a "Visual Studio 9 2008" solution file for an Intel Visual Fortran 11 project, CMake is unable to run the compiler because the .vfproj file associated with ifort version 11 is sufficiently different from the 9.1 version.

Discussion on this topic is on the CMake Mail list 12/11/2008 (originator: Tormod.Ravnanger.Landet@dnv.com). Bill comments that the fix should be easy and it may be in his queue.


Steps To Reproduce
Additional InformationSetup:
1. Visual Studio 2008 with SP1
2. Intel Visual Fortran version 11.

Source code:
[bar.f]
       program bar
           print *, "hello"
       end program bar

[CMakeLists.txt]
cmake_minimum_required(VERSION 2.6)
project(ivf11fails Fortran)
add_executable( bar_exe bar.f )
set_target_properties( bar_exe PROPERTIES LINKER_LANGUAGE Fortran )

Procedure:
1. Start IVF command prompt from the start menu.
2. cmake -G"Visual Studio 9 2008" /path/to/source

Error:
The Fortran compiler "C:/Program Files (x86)/Intel/Compiler/11.0/074/fortran/Bin/IA32/ifort.exe" is not able to compile a simple test program.

Comments:
1. The "NMake Makefiles" generator works fine. This is my current work around.
2. Originally reported on CMake Mailing List on 12/11/2008 by Tormod.Ravnanger.Landet@dnv.com. The conclusion of this discussion is that:
"Visual Studio asks me to upgrade the .vfproj file (in an irreversible way). Supposedly the Intel Fortran Visual Studio support has changed so that only Fortran specific info is contained in this file. This was done to avoid having
to sync the .vfproj and .vfproj files (or something like that)."
3. The CMake source code can be modified to provide a partial fix. cmLocalVisualStudio7Generator.cxx, mLocalVisualStudio7Generator::WriteProjectStartFortran can be modified to print "11.0" instead of "9.1" for the Version number. With this change, CMake will generate a .sln file. However, the .sln file does not appear to be valid and running "devenv" does not actually compile anything. The .vfproj file for this test is attached as cmake264_hack_v11.vfproj.
4. I have created a native Visual Studio 9 + IVF11 project that has the same "hello world" program. the .vfproj file for this test is attached as VS9_IVF11_native.vfproj.
TagsNo tags attached.
Relationships
Attached Fileszip sample_vfproj.zip (2,294) 2009-06-16 19:59
https://public.kitware.com/Bug/file/2332/sample_vfproj.zip
patch IFort11.patch (2,783) 2009-07-23 04:11
https://public.kitware.com/Bug/file/2382/IFort11.patch
Issue History
Date ModifiedUsernameFieldChange
2009-06-16 19:59Kelly ThompsonNew Issue
2009-06-16 19:59Kelly ThompsonFile Added: sample_vfproj.zip
2009-07-08 08:55Martin ApelNote Added: 0016830
2009-07-23 04:11Nils GladitzFile Added: IFort11.patch
2009-07-23 04:16Nils GladitzNote Added: 0016949
2009-09-11 17:38Bill HoffmanStatusnew => assigned
2009-09-11 17:38Bill HoffmanAssigned To => Brad King
2009-09-11 17:38Bill HoffmanNote Added: 0017393
2009-09-16 10:43Brad KingNote Added: 0017557
2009-09-16 11:04Brad KingNote Added: 0017558
2009-09-16 11:46Brad KingNote Added: 0017561
2009-09-16 11:48Brad KingNote Added: 0017562
2009-09-16 11:48Brad KingStatusassigned => resolved
2009-09-16 11:48Brad KingResolutionopen => fixed
2009-09-16 11:49Brad KingStatusresolved => feedback
2009-09-16 11:49Brad KingResolutionfixed => reopened
2009-09-16 17:27Kelly ThompsonNote Added: 0017576
2009-09-16 17:42Brad KingNote Added: 0017578
2009-09-17 14:35Kelly ThompsonNote Added: 0017594
2009-09-17 15:35Brad KingNote Added: 0017596
2009-09-17 15:35Brad KingStatusfeedback => closed
2009-09-17 15:35Brad KingResolutionreopened => fixed

Notes
(0016830)
Martin Apel   
2009-07-08 08:55   
A fix for this issue would be important to me as well. NMake is only a very limited workaround, because with NMake parallel compilation is not possible anymore.
(0016949)
Nils Gladitz   
2009-07-23 04:16   
I have attached a patch that fixes the issue with Intel's Fortran v11 for us.
It should detect the ifort version by preprocessing a small test file that will expand a version macro (mostly copied from Windows-cl.cmake).
The fortran project version is then set to 9.10 per default and corrected to
11.0 if the reported version is greater or equal to 1100 (11.0).

For this to actually work I had to run cmake from within the fortran build environment (e.g. ifort needs to be in PATH since CMakeDetermineFortranCompiler.cmake only sets CMAKE_Fortran_COMPILER to ifort without path)

P.S. only tested with Intel Fortran 11.0 and the Visual Studio 2005 generator.
(0017393)
Bill Hoffman   
2009-09-11 17:38   
Brad can you test with the intel compiler at Kitware?
(0017557)
Brad King   
2009-09-16 10:43   
I've tested this with the VS 2008 generator, and it works.

However, I'd like to avoid requiring the user to start cmake from a command prompt. A major point of the IDE generators is that they can be used with GUI-only tools.

Does anyone know how to detect which Intel version is currently plugged into VS?
I'm sure there are registry entries for it. Also, can more than one version of Intel be installed and/or plugged into VS at the same time?
(0017558)
Brad King   
2009-09-16 11:04   
I have VS 7.1, 8, and 9 installed and told Intel Fortran 11.0 to plug into each of them. I see these registry keys:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Packages\{B68A201D-CB9B-47AF-A52F-7EEC72E217E4}
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Packages\{B68A201D-CB9B-47AF-A52F-7EEC72E217E4}
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Packages\{B68A201D-CB9B-47AF-A52F-7EEC72E217E4}

Each key has a "ProductVersion" value that is set to "11.0".

Every VS plugin has a unique GUID, and B68A201D-CB9B-47AF-A52F-7EEC72E217E4 appears to be that GUID for the VFProj plugin DLL. Searching the web for this value finds hits on discussion of this plugin from earlier Intel compiler versions.

Can anyone verify that these keys are present on your systems too (note if you have a 64-bit machine they might be in SOFTWARE\Microsoft\Wow6432Node\... instead of SOFTWARE\Microsoft\...)?
(0017561)
Brad King   
2009-09-16 11:46   
I've made the commits below to fix this assuming the registry entries are correct. Now CMake always writes the current Intel compiler plugin version into the .vfproj files.

Create VS generator GetRegistryBase method
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio10Generator.h,v <-- Source/cmGlobalVisualStudio10Generator.h
new revision: 1.4; previous revision: 1.3
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio6Generator.h,v <-- Source/cmGlobalVisualStudio6Generator.h
new revision: 1.31; previous revision: 1.30
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio71Generator.h,v <-- Source/cmGlobalVisualStudio71Generator.h
new revision: 1.20; previous revision: 1.19
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.h,v <-- Source/cmGlobalVisualStudio7Generator.h
new revision: 1.51; previous revision: 1.50
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio8Generator.h,v <-- Source/cmGlobalVisualStudio8Generator.h
new revision: 1.16; previous revision: 1.15
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio9Generator.h,v <-- Source/cmGlobalVisualStudio9Generator.h
new revision: 1.5; previous revision: 1.4
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.cxx,v <-- Source/cmGlobalVisualStudioGenerator.cxx
new revision: 1.17; previous revision: 1.16
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.h,v <-- Source/cmGlobalVisualStudioGenerator.h
new revision: 1.11; previous revision: 1.10

Generate proper Intel Fortran project version

/cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v <-- Source/cmLocalVisualStudio7Generator.cxx
new revision: 1.251; previous revision: 1.250
(0017562)
Brad King   
2009-09-16 11:48   
I'm leaving this resolved instead of closed for now in case anyone has links or test results to verify the solution.
(0017576)
Kelly Thompson   
2009-09-16 17:27   
I am using Intel Fortran 11.1 with Visual Studio 9 2008 on Windows XP/x64.

My registry entries are slightly different than the ones you list. Wow6432Node and Microsoft are switched:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Packages\{B68A201D-CB9B-47AF-A52F-7EEC72E217E4}]
@="Intel(R) Visual Fortran Project Package"
"InprocServer32"="C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\Intel Fortran\\VFPackages\\VFProj.dll"
"CompanyName"="Intel Corporation"
"ProductName"="Intel Fortran Compiler Integration Package, Project System"
"ProductVersion"="11.1"
"MinEdition"="Standard"
"ID"=dword:00000001

Also, my product version is 11.1 instead of 11.0, but I don't think that is critical.

I will try out your changes with after the nightly CVS builds are posted. Am I correct in understanding that these changes will be available in the 9/17/2009 build found at http://www.cmake.org/files/vCVS. [^]
(0017578)
Brad King   
2009-09-16 17:42   
Oops, the location of Wow6432Node is the same for me as for you. I just mis-typed the example.

The key is that the GUID is the same for the plugin.

Yes, the fix should be in tonight's nightly build.
(0017594)
Kelly Thompson   
2009-09-17 14:35   
I can confirm that cmake-2.7.20090917-win32-x86.exe no longer exhibits this issue. I tried 32 and 64-bit builds of the sample program and was able to build both Debug and Release builds.

Note: the Release builds would not link w/o adding

set( CMAKE_EXE_LINKER_FLAGS_RELEASE "/subsystem:console" )

to the sample CMakeLists.txt

Now, its time to try the real code ...
(0017596)
Brad King   
2009-09-17 15:35   
Great, thanks for trying it. Please submit a separate issue for the /subsystem:console problem.