View Issue Details [ Jump to Notes ] [ Print ]
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.


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.
Attached Fileszip file icon sample_vfproj.zip [^] (2,294 bytes) 2009-06-16 19:59
patch file icon IFort11.patch [^] (2,783 bytes) 2009-07-23 04:11 [Show Content]

 Relationships

  Notes
(0016830)
Martin Apel (reporter)
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 (developer)
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 (manager)
2009-09-11 17:38

 Brad can you test with the intel compiler at Kitware?
(0017557)
Brad King (manager)
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 (manager)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
2009-09-17 15:35

 Great, thanks for trying it. Please submit a separate issue for the /subsystem:console problem.

 Issue History
Date Modified Username Field Change
2009-06-16 19:59 Kelly Thompson New Issue
2009-06-16 19:59 Kelly Thompson File Added: sample_vfproj.zip
2009-07-08 08:55 Martin Apel Note Added: 0016830
2009-07-23 04:11 Nils Gladitz File Added: IFort11.patch
2009-07-23 04:16 Nils Gladitz Note Added: 0016949
2009-09-11 17:38 Bill Hoffman Status new => assigned
2009-09-11 17:38 Bill Hoffman Assigned To => Brad King
2009-09-11 17:38 Bill Hoffman Note Added: 0017393
2009-09-16 10:43 Brad King Note Added: 0017557
2009-09-16 11:04 Brad King Note Added: 0017558
2009-09-16 11:46 Brad King Note Added: 0017561
2009-09-16 11:48 Brad King Note Added: 0017562
2009-09-16 11:48 Brad King Status assigned => resolved
2009-09-16 11:48 Brad King Resolution open => fixed
2009-09-16 11:49 Brad King Status resolved => feedback
2009-09-16 11:49 Brad King Resolution fixed => reopened
2009-09-16 17:27 Kelly Thompson Note Added: 0017576
2009-09-16 17:42 Brad King Note Added: 0017578
2009-09-17 14:35 Kelly Thompson Note Added: 0017594
2009-09-17 15:35 Brad King Note Added: 0017596
2009-09-17 15:35 Brad King Status feedback => closed
2009-09-17 15:35 Brad King Resolution reopened => fixed

Copyright © 2000 - 2018 MantisBT Team