View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015831CMakeCMakepublic2015-11-04 02:352016-06-10 14:21
ReporterYuan Hong 
Assigned ToBrad King 
PriorityhighSeverityblockReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformWindowsOSWindows 10OS Version10240
Product Version 
Target VersionCMake 3.4.2Fixed in VersionCMake 3.4.2 
Summary0015831: CMake Version 3.4 with VS 2015 fails to detect a Windows 10 SDK
DescriptionWhen I use Version 3.3 and 3.4.0 rc1, I can make the build success with My Visual Studio 2015. but when i try to cmake -G "Visual Studio 14 Win64" ..\ with version 3.4.0 rc2 (and rc3), I get follow error:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:3 (project):
  No CMAKE_C_COMPILER could be found.



CMake Error at CMakeLists.txt:3 (project):
  No CMAKE_CXX_COMPILER could be found.



-- Configuring incomplete, errors occurred!
See also "C:/Work/obs-studio/build64/CMakeFiles/CMakeOutput.log".
See also "C:/Work/obs-studio/build64/CMakeFiles/CMakeError.log".


and the most important error in CMakeError.log is :

ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /nologo /W0 /WX- /Od /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TC /errorReport:queue CMakeCCompilerId.c
  CMakeCCompilerId.c
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' [C:\Work\obs-studio\build64\CMakeFiles\3.4.0-rc3\CompilerIdC\CompilerIdC.vcxproj]
Steps To Reproducecmake with my attached CMakeList file.
TagsNo tags attached.
Attached Filestxt file icon CMakeLists.txt [^] (3,497 bytes) 2015-11-04 02:35 [Show Content]
zip file icon Issue15831.zip [^] (97,315 bytes) 2015-11-05 19:30
cxx file icon cmGlobalVisualStudio14Generator.cxx [^] (10,209 bytes) 2016-01-03 05:59

 Relationships
has duplicate 0015875closed CMake does not find the VS2015 C compiler even though it has been installed by building a C/C++ program 
has duplicate 0015884closed 3.4.1 regression for vs2015 detection 
related to 0015929closedBrad King "Could not find an appropriate version of the Windows 10 SDK" 

  Notes
(0039832)
Brad King (manager)
2015-11-04 08:59

I cannot reproduce this. Please try a fresh build tree and a CMakeLists.txt file containing just

 cmake_minimum_required(VERSION 2.8.12)
 project(Issue15831 C)
(0039835)
Yuan Hong (reporter)
2015-11-04 19:35

Use the two line CMakeLists.txt, I get the same error.
Attache file is the build tree. and the build dir is for VS2015, build32 dir is for VS2013, which success.
(0039837)
Brad King (manager)
2015-11-05 11:37

Re 0015831:0039835: Thanks for trying the simple example. I don't see a new attachment though. Please also build with 3.4.0-rc1 for VS2015 in another directory so we can compare what it does with the failure observed for 3.4.0-rc3.
(0039839)
Yuan Hong (reporter)
2015-11-05 19:31

I have add the attach file.
(0039843)
Brad King (manager)
2015-11-06 09:11

Thanks for the tests. The difference between the compiler id test files is:

 $ diff -u build-2015-rc1/CMakeFiles/3.4.0-rc1/CompilerIdC/CompilerIdC.vcxproj build-2015-rc3/CMakeFiles/3.4.0-rc3/CompilerIdC/CompilerIdC.vcxproj
 ...
 + <WindowsTargetPlatformVersion>10.0.10240</WindowsTargetPlatformVersion>
 ...


The one without WindowsTargetPlatformVersion works.

Please check if 3.4.0-rc2 shows that line or not.

Are you using the upstream-provided pre-built rc binaries? If not, then how did you build these?
(0039846)
Gilles Khouzam (developer)
2015-11-06 14:24
edited on: 2015-11-06 14:25

It looks like the issue is in the code trying to detect the version of the SDK that is installed.

Can you change the WindowsTargetPlatformVersion to be 10.0.10240.0 instead of 10.0.10240 and see if the project builds?

Can you show what subfolders are present in the following directories? (I'm assuming that you install is on the C: Drive).
C:\Program Files (x86)\Windows Kits\10\Lib
C:\Program Files (x86)\Windows Kits\10\Include

Also can you update the CMakeLists.txt to include the following message:

 cmake_minimum_required(VERSION 2.8.12)
 project(Issue15831 C)
 message("Current CMAKE_SYSTEM_VERSION = ${CMAKE_SYSTEM_VERSION}")

For some reason, the version being set is missing the final .0.

(0039847)
Yuan Hong (reporter)
2015-11-08 20:32

I can msbuild the CompilerIdC project when change the WindowsTargetPlatformVersion to be 10.0.10240.0

I have two subfolders on
C:\Program Files (x86)\Windows Kits\10\Lib
C:\Program Files (x86)\Windows Kits\10\Include

10.0.10150.0
and 10.0.10240.0

But when use vcvarsall.bat I have these env:

INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Progra
m Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x
86)\Windows Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows Kit
s\NETFXSDK\4.6\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.10
240\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.10240\um;C:\Progr
am Files (x86)\Windows Kits\10\include\10.0.10240\winrt;

LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows
Kits\10\lib\10.0.10240.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4
.6\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240\um\x86;

WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
WindowsSDKLibVersion=10.0.10240\
WindowsSDKVersion=10.0.10240\
WindowsSDK_ExecutablePath_x64=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.
0A\bin\NETFX 4.6 Tools\x64\
WindowsSDK_ExecutablePath_x86=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.
0A\bin\NETFX 4.6 Tools\
(0039849)
Brad King (manager)
2015-11-09 08:56

Yuan, while Gilles works with you to pin down the underlying issue, I'd like to also try to understand why the behavior changed for you during the 3.4.0-rc series. AFAICT none of our changes between release candidates could have caused WindowsTargetPlatformVersion to show up if it did not before. What may affect it though is how the binary of CMake itself was built (to enable it to detect when running on a Windows 10 host).

Are you using the upstream-provided pre-built rc binaries? If not, then how did you build these?
(0039851)
Gilles Khouzam (developer)
2015-11-09 16:23

Hi Yuan,

Can you confirm that you have both 10.0.10150.0 and 10.0.10240.0 in the C:\Program Files (x86)\Windows Kits\10\Include directory? From the look of your environment, I'm guessing that the Include folder somehow got renamed to 10.0.10240.

CMake emulates what VCVars does.
The code to set the WindowsSDKVersion is as follows and takes the
@if not "%WindowsSdkDir%"=="" @FOR /F "delims=" %%i IN ('dir "%WindowsSdkDir%include\" /b /ad-h /on') DO @set WindowsSDKVersion=%%i\
Which would only get version 10.0.10240 (without the final .0) if the folder got renamed somehow.

Would you mind double checking this?
(0039852)
Yuan Hong (reporter)
2015-11-09 20:24

1. I download the rc builds from cmake.org
2. I have two subfolders on
C:\Program Files (x86)\Windows Kits\10\Lib
C:\Program Files (x86)\Windows Kits\10\Include

10.0.10150.0
and 10.0.10240.0 and noting more
(0039857)
Brad King (manager)
2015-11-10 09:59

It looks like the manifest embedded into cmake.exe in the cmake.org 3.4.0-rc1 build did not have the <compatibility/> attribute needed to recognize Windows 10 hosts. Looking back through the logs it appears the script used to create the release was not updated to use the newer cmake on the build machine needed to embed the explicit manifest file. The change was committed days earlier but not checked out on the actual build machine. The checkout was then made the next day so 3.4.0-rc2 and later built with the correct manifest.

This explains why 3.4.0-rc1 did not have this problem but rc2 and rc3 do even though no actual code changes related to this were made.

------------------------------------------------------------

We still need to understand how the ".0" ends up missing from WindowsTargetPlatformVersion on Yuan's machine. If the directories that exist on disk are named "10.0.10240.0" then how does the detection end up getting "10.0.10240"? Yuan reported that vcvarsall.bat produces these INCLUDE and LIB directories from the SDK:

 C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt
 C:\Program Files (x86)\Windows Kits\10\include\10.0.10240\shared
 C:\Program Files (x86)\Windows Kits\10\include\10.0.10240\um
 C:\Program Files (x86)\Windows Kits\10\include\10.0.10240\winrt

 C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86
 C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240\um\x86

If those do not exist on disk then how does even a basic command-line build even work from such an environment?
(0039865)
Brad King (manager)
2015-11-11 13:22

I tested a fresh Win 10 install with a fresh VS 2015 install and CMake 3.4.0-rc3. Everything works as expected. The compiler id test project has

 <WindowsTargetPlatformVersion>10.0.10240.0</WindowsTargetPlatformVersion>

as expected. The "C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\" directory exists and is used for detecting the SDK version correctly.

Yuan, as no one else seems to be able to reproduce this I don't think we can help further without running more tests on your machine. Please take a look at the source code in cmGlobalVisualStudio14Generator::GetWindows10SDKVersion here:

 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudio14Generator.cxx;hb=v3.4.0-rc3#l232 [^]

Can you build CMake from source and debug the detection locally? Note that you need to build using 3.4.0-rc3 (perhaps using your VS 2013) in order to get a CMake that knows how to recognize the Windows 10 host.
(0039959)
drivehappy (reporter)
2015-12-07 18:29
edited on: 2015-12-07 18:31

Hi, I'm also experiencing this issue with 3.4.1 (x64). The 3.3.2 (x64) seems to work as expected. I'm not familiar with the details of CMake, so if I need to provide specific files please let me know.

Details:
With CMake 3.4.1 VS2015 (Update 1 - Enterprise) doesn't work, I get:
     [echo] Generator: Visual Studio 14 2015 Win64
     [exec] -- The CXX compiler identification is unknown

With CMake 3.3.2 VS2015 (Update 1) works:
     [echo] Generator: Visual Studio 14 2015 Win64
     [exec] -- The CXX compiler identification is MSVC 19.0.23506.0
     [exec] -- The C compiler identification is MSVC 19.0.23506.0
     [exec] -- Check for working CXX compiler using: Visual Studio 14 2015 Win64
     [exec] -- Check for working CXX compiler using: Visual Studio 14 2015 Win64 -- works

VS2013 (Update 5 - Premium) works with 3.4.1.


Edit: In case this is useful, my C:\Program Files (x86)\Windows Kits\10\Include has the following:
  10.0.10150.0
  10.0.10240.0
  10.0.10586.0
  wdf

My Developer Command Prompt (vcvarsall) reports:
  echo %WindowsSDKLibVersion%
  10.0.10586.0\

  echo %WindowsSDKVersion%
  10.0.10586.0\

(0039960)
Brad King (manager)
2015-12-08 08:28

Re 0015831:0039959: Thanks. We're unable to reproduce this so if you can please look at local debugging as requested in 0015831:0039865. Use CMake 3.4.1 and VS 2013 to build CMake from source so you can debug it.
(0039970)
drivehappy (reporter)
2015-12-11 12:22

Hi Brad,

Unfortunately at the time I was in the middle of a different problem I needed to solve, and now on the same system I cannot reproduce the issue. In case this is useful for anyone:

* I did not restart my system between when it was occurring and now
* No Visual Studio configuration changes

If I run across this again I will try to dig into why it's occurring with a debug build.
(0040044)
DPD (reporter)
2016-01-03 05:57
edited on: 2016-01-03 05:58

Hi,

I'm in the same situation of drivehappy. I'm experiencing this issue with 3.4.1 but with the 3.3.2 works as expected.
As Brad King suggest, I'm get the source of CMake 3.4.1 for local debugging it using VS 2010.

I look into vcvarsall.bat how the Windows 10 SDK version is get and I discover that vcvarsall.bat check for the presence of the Windows.h file in side the sub folder \um for validate an SDK version.

Following the code inside the vcvarsall.bat:

@REM get windows 10 sdk version number
@setlocal enableDelayedExpansion
@if not "%WindowsSdkDir%"=="" @for /f %%i IN ('dir "%WindowsSdkDir%include\" /b /ad-h /on') DO (
    @REM Skip if Windows.h is not found in %%i\um. This would indicate that only the UCRT MSIs were
    @REM installed for this Windows SDK version.
    @if EXIST "%WindowsSdkDir%include\%%i\um\Windows.h" (
        @set result=%%i
        @if "!result:~0,3!"=="10." (
            @set SDK=!result!
            @if "!result!"=="%user_inputversion%" set findSDK=1
        )
    )
)


Consequently I check the contents of all my 3 version of SDK version (10.0.10150.0, 10.0.10240.0, 10.0.10586.0) and actually the 10.0.10150.0 and 10.0.10240.0 are not a complete SDK installation (for same unknow reason).

So I add the check for Windows.h file presence inside the function cmGlobalVisualStudio14Generator::GetWindows10SDKVersion(). After this the versions 10.0.10150.0 and 10.0.10240.0 are correctly skipped.
But this is not sufficient because the version 10.0.10586.0 is skipped by the test with the SystemVersion. I don't know why this test exist but the vcvarsall.bat not do anything like that, the vcvarsall.bat simple get always the most recent version of the SDK.

I attached the modified version of the cmGlobalVisualStudio14Generator.cxx file, where I change only the content of the function cmGlobalVisualStudio14Generator::GetWindows10SDKVersion().

(0040046)
danmal (reporter)
2016-01-03 20:15
edited on: 2016-01-04 10:30

Hello, I'm experiencing the same issue. I'm not sure (since it's on appveyor CI) but it looks that the problem came from updating vs 2015 to update 1. (it worked with vs without update and cmake 3.4.0).
Here are error logs: http://pastebin.com/dbCpRwvd [^]
UPD: it started working for some reason but still breaks with -DCMAKE_SYSTEM_VERSION=10.0.10240.0 (works with -DCMAKE_SYSTEM_VERSION=10.0.10586.0)

(0040156)
Brad King (manager)
2016-01-08 10:11

Re 0015831:0040044 and 0015831:0040046: Thank you both for this information. Please try out this fix:

 VS: Do not select a partial Windows 10 SDK folder
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c173e37f [^]

Using -DCMAKE_SYSTEM_VERSION=10.0.10240.0 when only the 10.0.10586.0 is available should still break since the SDK version is not available, but will now show an error message saying so, e.g.

 CMake Error at CMakeLists.txt:3 (project):
   Could not find an appropriate version of the Windows 10 SDK installed on
   this machine
(0040157)
danmal (reporter)
2016-01-08 10:24
edited on: 2016-01-08 10:26

Does it use available SDK if it fails?
I mean it seems that in my case it failed because there was incomplete 10.0.10240.0 install and complete 10.0.10586.0 sdk, but without any additional params it tried to use 10.0.10240.0 for some reason and failed without recovering.
UPD: Checked it more thoroughly and it seems OK. I still don't know why it tried to use older SDK when newer should have been available though. I thought it supposed to use newest by default.

(0040158)
Brad King (manager)
2016-01-08 10:38

Re 0015831:0040157: The default CMAKE_SYSTEM_VERSION is the CMAKE_HOST_SYSTEM_VERSION, which is the version of Windows running on the host. The code here:

 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudio14Generator.cxx;hb=v3.4.1#l276 [^]

accepts the largest SDK version that is not newer than CMAKE_SYSTEM_VERSION.

IIRC it was designed this way because one should not build with a SDK newer than the deployment target version. However, this also means that if the only SDK available is newer than the host version of Windows then the build will break by default always.

Gilles?
(0040161)
Gilles Khouzam (developer)
2016-01-08 11:48

You should be able to use the latest SDK installed on the system no matter what your host system by setting the CMAKE_SYSTEM_VERSION to 10.0.

The logic is 10.0 uses the latest SDK, 10.0.something uses the closest matched SDK not greater than the system version.

    // Select a suitable SDK version.
    if (this->SystemVersion == "10.0")
      {
      // Use the latest Windows 10 SDK since no build version was given.
      return sdks.at(0);
      }
    else
      {
      // Find the SDK less or equal to our specified version
      for (std::vector<std::string>::iterator i = sdks.begin();
           i != sdks.end(); ++i)
        {
        if (!cmSystemTools::VersionCompareGreater(*i, this->SystemVersion))
          {
          // This is the most recent SDK that we can run safely
          return *i;
          }
        }
      }
(0040162)
Brad King (manager)
2016-01-08 11:54

Re 0015831:0040161: Yes, but my concern is that the default behavior is for CMAKE_SYSTEM_VERSION to be the CMAKE_HOST_SYSTEM_VERSION which is more-specific than "10.0". Therefore pure host-only builds break by default if the SDK is newer.
(0040175)
Jonas El Sayeh Khalil (reporter)
2016-01-11 05:28

Hi, suprisingly enough the solution that worked for me was to uninstall the SDK ...

My system (company-controlled) is still windows build 10240 (maybe few people have issues because their system is nicely upgraded to build 10586?)...
- Visual studio leaves the windowssdk-path blank (hence, kernel32.dll is not found)

After uninstalling the Win10 SDK:
- Visual studio now uses a path to 8.1

Both with the exact same project file generated by CMake ... I have no idea why MSVC uses 8.1 if you ask for 10.0.10240 without 10.0.10586 installed, while refusing to use 8.1 if you ask for 10.0.10240 WITH 10.0.10586 installed ... Seems to me that the issue lies in the camp of Microsoft, but I'm no expert ... Also, indeed CMake 3.3.2 does work, because here, no WindowsTargetPlatformVersion is given in the MSVC project (so I guess MSVC does use the Win10 SDK then, although I did not check before uninstalling ...)

I hope this information does help in some way ...
(0040184)
Brad King (manager)
2016-01-11 10:41

Re 0015831:0040162: The logic we've developed for OS X SDK selection is here:

 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.4.1#l79 [^]
 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.4.1#l83 [^]

Basically it prefers the explicitly requested deployment target version and if that is not found uses the latest SDK available. Then it also rejects with an error SDKs that are *older* than the deployment target. This is basically backward from what is currently done for the Windows SDK (where we do not want any SDK newer than the deployment target), which came from discussion here:

 [Patch] Adding Windows 10 support, 2015-09-25 18:52:48 GMT
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14201/focus=14564 [^]

I think that my suggestion there is backward.

The approach we're using for OS X makes more sense because it is up to the application to not use APIs newer than the target platform version, but up to the build system to provide a SDK that is new enough to have all APIs needed by the target platform version.
(0040193)
Brad King (manager)
2016-01-11 13:56

Re 0015831:0040184: After adding a helper:

 cmSystemTools: Add VersionCompareEqual helper
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad594de8 [^]

I've implemented the corrected Windows 10 SDK selection logic here:

 VS: Fix Windows 10 SDK version selection (0015831)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57caf7e [^]
(0040201)
Brad King (manager)
2016-01-12 11:00

After the changes linked in 0015831:0040156 and 0015831:0040193 we now always select a Windows 10 SDK if any exists that contains "um/windows.h". We prefer an exact version match and otherwise choose the latest SDK available.

The symptom described in 0015831:0039843 still has not been reproduced anywhere else, so unless it comes up again I now think this issue is resolved.
(0041278)
Kitware Robot (administrator)
2016-06-10 14:21

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2015-11-04 02:35 Yuan Hong New Issue
2015-11-04 02:35 Yuan Hong File Added: CMakeLists.txt
2015-11-04 08:59 Brad King Note Added: 0039832
2015-11-04 19:35 Yuan Hong Note Added: 0039835
2015-11-05 11:37 Brad King Note Added: 0039837
2015-11-05 19:30 Yuan Hong File Added: Issue15831.zip
2015-11-05 19:31 Yuan Hong Note Added: 0039839
2015-11-06 09:11 Brad King Note Added: 0039843
2015-11-06 14:24 Gilles Khouzam Note Added: 0039846
2015-11-06 14:25 Gilles Khouzam Note Edited: 0039846
2015-11-08 20:32 Yuan Hong Note Added: 0039847
2015-11-09 08:56 Brad King Note Added: 0039849
2015-11-09 16:23 Gilles Khouzam Note Added: 0039851
2015-11-09 20:24 Yuan Hong Note Added: 0039852
2015-11-10 09:59 Brad King Note Added: 0039857
2015-11-11 13:22 Brad King Note Added: 0039865
2015-12-07 18:29 drivehappy Note Added: 0039959
2015-12-07 18:31 drivehappy Note Edited: 0039959
2015-12-08 08:28 Brad King Note Added: 0039960
2015-12-09 11:17 Brad King Relationship added has duplicate 0015875
2015-12-11 12:22 drivehappy Note Added: 0039970
2015-12-17 08:35 Brad King Relationship added has duplicate 0015884
2016-01-03 05:57 DPD Note Added: 0040044
2016-01-03 05:58 DPD Note Edited: 0040044
2016-01-03 05:59 DPD File Added: cmGlobalVisualStudio14Generator.cxx
2016-01-03 20:15 danmal Note Added: 0040046
2016-01-03 21:05 danmal Note Edited: 0040046
2016-01-04 10:28 danmal Note Edited: 0040046
2016-01-04 10:30 danmal Note Edited: 0040046
2016-01-08 10:11 Brad King Note Added: 0040156
2016-01-08 10:24 danmal Note Added: 0040157
2016-01-08 10:26 danmal Note Edited: 0040157
2016-01-08 10:38 Brad King Note Added: 0040158
2016-01-08 11:48 Gilles Khouzam Note Added: 0040161
2016-01-08 11:54 Brad King Note Added: 0040162
2016-01-11 05:28 Jonas El Sayeh Khalil Note Added: 0040175
2016-01-11 10:41 Brad King Note Added: 0040184
2016-01-11 13:56 Brad King Note Added: 0040193
2016-01-12 11:00 Brad King Note Added: 0040201
2016-01-12 11:00 Brad King Assigned To => Brad King
2016-01-12 11:00 Brad King Status new => resolved
2016-01-12 11:00 Brad King Resolution open => fixed
2016-01-12 11:00 Brad King Fixed in Version => CMake 3.5
2016-01-12 11:00 Brad King Target Version => CMake 3.5
2016-01-12 11:00 Brad King Summary CMake Version 3.4.0 rc2 rc3 Detected Visual Studio 2015 with some error => CMake Version 3.4 with VS 2015 fails to detect compiler
2016-01-12 11:01 Brad King Summary CMake Version 3.4 with VS 2015 fails to detect compiler => CMake Version 3.4 with VS 2015 fails to detect a Windows 10 SDK
2016-01-20 10:24 Brad King Fixed in Version CMake 3.5 => CMake 3.4.2
2016-01-20 10:24 Brad King Target Version CMake 3.5 => CMake 3.4.2
2016-01-21 08:32 Brad King Relationship added related to 0015929
2016-06-10 14:21 Kitware Robot Note Added: 0041278
2016-06-10 14:21 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team