MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011279CMakeModulespublic2010-09-30 11:012011-11-11 10:45
ReporterAaron C. Meadows 
Assigned ToPhilip Lowman 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0011279: CMakeDetermineVSServicePack.cmake only supports vs2005, vs2005 sp1, vs2008, vs2008 sp1
DescriptionWith VS2010 out, it would be nice if this script supported it as well.

I've created a patch to correct this issue.
Steps To Reproduce
Additional InformationThe script works by try_compile'ing a simple c file, then capturing the output and capturing the version number with a regex. It could be modified to just invoke the compiler with '/?' and load the version from there without generating and compiling files. That would make detection quite a bit faster.
Tags2010, msvc10, visual studio 2010
Relationships
Attached Filespatch CMakeDetermineVSServicePack.cmake.patch (478) 2010-09-30 11:01
https://public.kitware.com/Bug/file/3423/CMakeDetermineVSServicePack.cmake.patch
patch CMakeDetermineVSServicePack.cmake.vs2010msbuild.patch (1,307) 2011-06-06 18:50
https://public.kitware.com/Bug/file/3915/CMakeDetermineVSServicePack.cmake.vs2010msbuild.patch
patch CMakeDetermineVSServicePack.cmake.FastAnd2010.patch (4,931) 2011-06-09 16:16
https://public.kitware.com/Bug/file/3926/CMakeDetermineVSServicePack.cmake.FastAnd2010.patch
patch CMakeDetermineVSServicePack.cmake.FastAnd2010revised.patch (4,993) 2011-06-10 10:21
https://public.kitware.com/Bug/file/3930/CMakeDetermineVSServicePack.cmake.FastAnd2010revised.patch
patch CMakeDetermineVSServicePack.cmake.FastAnd2010revised2.patch (6,494) 2011-06-10 10:59
https://public.kitware.com/Bug/file/3931/CMakeDetermineVSServicePack.cmake.FastAnd2010revised2.patch
Issue History
Date ModifiedUsernameFieldChange
2010-09-30 11:01Aaron C. MeadowsNew Issue
2010-09-30 11:01Aaron C. MeadowsFile Added: CMakeDetermineVSServicePack.cmake.patch
2010-09-30 17:05Bill HoffmanStatusnew => assigned
2010-09-30 17:05Bill HoffmanAssigned To => Philip Lowman
2010-09-30 21:37Philip LowmanNote Added: 0022394
2010-09-30 21:39Philip LowmanFixed in Version => CMake 2.8.3
2010-09-30 21:39Philip LowmanTarget Version => CMake 2.8.3
2010-09-30 21:43Philip LowmanNote Added: 0022395
2010-09-30 21:43Philip LowmanStatusassigned => resolved
2010-09-30 21:43Philip LowmanResolutionopen => fixed
2010-11-09 22:57Philip LowmanStatusresolved => closed
2011-06-06 18:50Aaron C. MeadowsNote Added: 0026731
2011-06-06 18:50Aaron C. MeadowsStatusclosed => feedback
2011-06-06 18:50Aaron C. MeadowsResolutionfixed => reopened
2011-06-06 18:50Aaron C. MeadowsFile Added: CMakeDetermineVSServicePack.cmake.vs2010msbuild.patch
2011-06-06 18:52Aaron C. MeadowsTag Attached: 2010
2011-06-06 18:52Aaron C. MeadowsTag Attached: msvc10
2011-06-06 18:53Aaron C. MeadowsTag Attached: visual studio 2010
2011-06-07 13:54Bill HoffmanStatusfeedback => confirmed
2011-06-07 13:54Bill HoffmanTarget VersionCMake 2.8.3 => CMake 2.8.5
2011-06-08 16:03Aaron C. MeadowsNote Added: 0026772
2011-06-08 16:39Aaron C. MeadowsNote Added: 0026775
2011-06-09 16:16Aaron C. MeadowsFile Added: CMakeDetermineVSServicePack.cmake.FastAnd2010.patch
2011-06-09 16:23Aaron C. MeadowsNote Added: 0026811
2011-06-09 22:01Philip LowmanNote Added: 0026813
2011-06-10 10:21Aaron C. MeadowsNote Added: 0026822
2011-06-10 10:21Aaron C. MeadowsFile Added: CMakeDetermineVSServicePack.cmake.FastAnd2010revised.patch
2011-06-10 10:59Aaron C. MeadowsFile Added: CMakeDetermineVSServicePack.cmake.FastAnd2010revised2.patch
2011-06-10 11:03Aaron C. MeadowsNote Added: 0026824
2011-06-15 08:58Philip LowmanNote Added: 0026871
2011-06-15 08:58Philip LowmanStatusconfirmed => resolved
2011-06-15 08:58Philip LowmanResolutionreopened => fixed
2011-06-15 08:58Philip LowmanFixed in VersionCMake 2.8.3 => CMake 2.8.5
2011-11-11 10:45David ColeNote Added: 0027766
2011-11-11 10:45David ColeStatusresolved => closed

Notes
(0022394)
Philip Lowman   
2010-09-30 21:37   
Aaron, thanks for the patch. I've pushed it to git next.
Regarding your idea to use the output of "cl /?" to determine the version number, I think it is a good one. If you have time to rewrite the module to do this instead and test it I would merge the changes for a future version of CMake.

Some potential issues.
1. "cl /?" appears to pause waiting for input, this would have to be mitigated somehow in a safe way or perhaps just "cl" could be executed as that appears to include the output.
2. "cl" or "cl /?" output would have to be verified on VS8 to ensure it outputs there as well (it appears to be there in VS9/Express)
3. You couldn't just run "cl", you would have to find out the CMake variable for the compiler and run that.

My time is really limited. If you're interested, please create a new ticket and submit a patch. It would save probably at least a second off of an initial configure.
(0022395)
Philip Lowman   
2010-09-30 21:43   
I'm going to resolve this since I don't want the new Roadmap to show any open issues. If you have any comments please reply on the mailing list.
(0026731)
Aaron C. Meadows   
2011-06-06 18:50   
This file is broken again by the switch of VS2010 from using CL.exe to MSBuild.exe. I have a patch to fix it.
(0026772)
Aaron C. Meadows   
2011-06-08 16:03   
hmm.. I just upgraded to VS2010 Sp1. The current technique of detecting service pack will not work for it. After the update, MSBuild was still reporting a version of 4.00.300319.01. However, cl.exe moved from 16.00.30319.01 to 16.00.40219.01.

A while back I started an issue to call cl.exe directly and pull a version from it, but there was some complaint over what happened when cl.exe was not in the path. I'm not sure how to find that now, maybe it was on the mail list. Anyway, I'd suggest switching to that method to get the version.
(0026775)
Aaron C. Meadows   
2011-06-08 16:39   
I went back and looked at that defect, it was Issue 0011292

The point Bill Hoffman brought up was that cl.exe is not know unless you ran from a VS Command prompt, so it would fail if executed from an IDE. Bill indicated that try_compile jumps through hoops to get the Devenv.exe command, call it, and allow it to delegate to the compiler. In fact, that's why the break with MSBuild occurred to begin with, causing me to reopen this bug.
(0026811)
Aaron C. Meadows   
2011-06-09 16:23   
Ok, I've got a new patch that solves this problem and implements the faster checking by calling the compiler directly if possible.

Here's a breakdown of the changes:
1) There are now 3 methods used to check the version, called in order:
  a) If CMAKE_CXX_COMPILER is set, it will call it directly and get the version from it. This is by far the fastest and most reliable way, if available.
  b) Next, it will try_compile a simple file, and look for the Compiler Version in the output stream. This is the original way it was checking.
  c) Finally, it will try_run a small program which makes use of _MSC_FULL_VER. This macro is defined by the compiler since vs2008, and contains the concatenated first 3 sections of the version number. (so, 16.00.40219.01 is expressed as 160040219)

2) The external interface remains completely unchanged. I added 3 new internal functions, one for each of the methods above.
(0026813)
Philip Lowman   
2011-06-09 22:01   
Aaron,
The patch looks great. Thanks for working on this!

I have two questions.

1. Can we add something else to the internal function names to ensure uniqueness? '_CheckVersionWithTryCompile' just looked a little too generic to me even with the underscore.

2. Can you credit yourself in the copyright declaration?

It would say something like:
#=============================================================================
# Copyright 2009-2010 Kitware, Inc.
# Copyright 2009-2010 Philip Lowman <philip@yhbt.com>
# Copyright 2011 Aaron C. Meadows <your email>
(0026822)
Aaron C. Meadows   
2011-06-10 10:21   
What, and claim responsibility for this? =D

Ok, 1 and 2 done, patch uploaded
(0026824)
Aaron C. Meadows   
2011-06-10 11:03   
I thought of one case where the fast detection would be wrong: If you were running CMake with a generator which was different than the version of vcvars.bat you had run, it would detect the vcvars version and not the generator version. I've patched for that and tested it. I also moved some of the regex work which saves the need to perform it in the try_run case.

There are starting to be an overwhelming number of patch files, so just to be clear, use this one:
 CMakeDetermineVSServicePack.cmake.FastAnd2010revised2.patch
(0026871)
Philip Lowman   
2011-06-15 08:58   
Merged Aaron's patch to next. The patch improves performance/robustness and adds detection for VS 2010 SP1.

effb6bb Detect VS 2010 SP1, faster and more robust detection
(0027766)
David Cole   
2011-11-11 10:45   
Closing resolved issues that have not been updated in more than 4 months.