MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011292CMakeModulespublic2010-10-06 08:492010-11-18 23:51
ReporterAaron C. Meadows 
Assigned ToPhilip Lowman 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionnot fixable 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0011292: CMakeDetermineVSServicePack.cmake uses try_compile to get the compiler version. cl.exe /? is much faster
DescriptionUsing try_compile(), there is a lot more work going on than is necessary just to get the version from the compiler. It is present at the top of the help output in the same format. I've modified the script to use that command instead and it is quite a bit faster at picking out the version of the compiler.

Patch attached.
Steps To Reproduce
Additional InformationI tested this with VS2005 sp1, vs2008 sp1, and vs2010.
TagsNo tags attached.
Relationships
Attached Filespatch CMakeDetermineVSServicePack.Fast.patch (1,345) 2010-10-06 08:49
https://public.kitware.com/Bug/file/3429/CMakeDetermineVSServicePack.Fast.patch
Issue History
Date ModifiedUsernameFieldChange
2010-10-06 08:49Aaron C. MeadowsNew Issue
2010-10-06 08:49Aaron C. MeadowsFile Added: CMakeDetermineVSServicePack.Fast.patch
2010-11-09 21:57Philip LowmanStatusnew => assigned
2010-11-09 21:57Philip LowmanAssigned To => Philip Lowman
2010-11-09 22:27Bill HoffmanNote Added: 0023117
2010-11-10 01:49Aaron C. MeadowsNote Added: 0023119
2010-11-10 07:55Bill HoffmanNote Added: 0023130
2010-11-11 10:01Philip LowmanNote Added: 0023171
2010-11-18 23:42Philip LowmanCategoryCMake => Modules
2010-11-18 23:50Philip LowmanNote Added: 0023421
2010-11-18 23:51Philip LowmanStatusassigned => closed
2010-11-18 23:51Philip LowmanResolutionopen => not fixable

Notes
(0023117)
Bill Hoffman   
2010-11-09 22:27   
But this will only work if Cl is in the path, and setup correctly. So, we can't use this patch. It will break for most folks doing an IDE build.
(0023119)
Aaron C. Meadows   
2010-11-10 01:49   
Cl.exe doesn't need to be in the path, it just needs to be found by CMake and put in the CMAKE_CXX_COMPILER variable. I don't think I agree with your assessment that it will be broken for IDE builds. Is try_compile using some magic beyond the mentioned variable? I did not see these issues you bring up when I tested, but I will test specifically for that tomorrow.
(0023130)
Bill Hoffman   
2010-11-10 07:55   
But if cl is not in the PATH, and the PATH does not have the dll's it needs to run. The IDE try-compile is doing a magic of sorts. CMake finds the IDE executable, say devenv. When CMake runs devenv, devenv sets up all the environment information to be able to run the compiler. You have to run vcvars.bat in order to be able to invoke cl directly. That is why the IDE try-compiles have to use solution files to do anything with the compiler. Just google the CMake list and look at how many times someone has trouble getting the nmake generator to work because they did not run vcvars.bat before running CMake. And seriously, this is only run once per configuration, the savings will be totally minimal.
(0023171)
Philip Lowman   
2010-11-11 10:01   
Aaron,
It sounds like for this patch to be merged we would have to be reasonably sure that "cl.exe" is either statically linked or capable of being run (with the /? flags) without any special environment variables set. Can you do some testing to confirm this?

If we find that all of the versions of MSVC that CMakeDetermineVSServicePack supports work properly with /? with no special environment variables, we can still leave the try_compile() support in as a fallback if there are any errors running cl or parsing the version number (for future safety).
(0023421)
Philip Lowman   
2010-11-18 23:50   
Aaron,

I tried running "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\cl" tonight from a command prompt (Visual Studio Express C++ 2008). I was greeted with a popup dialog Window.

The program can't start because mspdb80.dll is missing from your computer. Try reinstalling the program to fix this problem.

I get the same error running "cl" after changing directories to the directory it is in.

I think this means unfortunately that the patch can't be accepted. Thanks for suggesting it though, it was a good idea. If you have any other ideas for improving CMake or many of it's modules please bring them up on the mailing list or create tickets.