MantisBT - CMake
View Issue Details
0013791CMakeCMakepublic2012-12-13 15:552015-03-02 08:57
jujjyl 
Brad King 
nonefeaturealways
closedfixed 
MicrosoftWindows8
CMake 2.8.10.1 
CMake 3.1CMake 3.1 
0013791: CMake does not support generating projects for Windows Phone 8.
I have not found an option to generate solution/project files for "Visual Studio 2012 Express for Windows Phone 8". The project files to target Windows Phone 8 differ somewhat of those from Windows Desktop 8 and Windows RT 8. I assume that since Windows RT 8 option doesn't yet exist, Windows Phone 8 targeting does not exist either?

Marking down this issue to discuss required additions towards supporting this.
I went through and compared .vcxproj files for Windows Phone 8 and Windows RT 8. The project file generated for "Visual Studio 11" requires at least the following modifications to allow Windows Phone 8 deployment:

 - Must add elements <RootNamespace>project name?</RootNamespace> <DefaultLanguage>en-US</DefaultLanguage> <MinimumVisualStudioVersion>11.0</MinimumVisualStudioVersion> <XapOutputs>true</XapOutputs> <XapFilename>Project_Name_$(Configuration)_$(Platform).xap</XapFilename> <WinMDAssembly>true</WinMDAssembly> to the <PropertyGroup Label="Globals"> section of the generated .vcxproj file.

 - Must replace <PlatformToolset>v110</PlatformToolset> with <PlatformToolset>v110_wp80</PlatformToolset>

 - Must remove default-added linking to the following libraries: kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;
 
 - Must add a line <Import Project="$(MSBuildExtensionsPath)\Microsoft\WindowsPhone\v$(TargetPlatformVersion)\Microsoft.Cpp.WindowsPhone.$(TargetPlatformVersion).targets" /> before the section <ImportGroup Label="ExtensionTargets"> in the .vcxproj file.

 - Must add a reference to assembly 'Platform.winmd' to the compiler options. The command line for this is "/FU Platform.winmd"

Note that the <AppContainerApplication>true</AppContainerApplication> element that exists for Win8RT project files is not present for Win8 Phone project files.

I hope this list is useful for someone that might be capable in implementing support for this in cmake. A good way to compare is to open VS2012 and create a new project from the native C++ Direct3D application template, which exists for both VS2012 Express for Windows 8 and V2012 Express for Windows Phone 8. Comparing the .vcxproj files gives a good diff of the changes.
No tags attached.
related to 0013749closed  Cannot target Windows 8 RT from CMake without workarounds. 
related to 0013511closed Brad King Add support for WinRT platforms and "metro" apps 
has duplicate 0014598closed Patrick R. Gansterer CMake 2.8.12 with "Visual Studio 11 ARM" generator fails to compile simple test program, 2.8.11 works 
patch a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch (1,345) 2013-12-04 09:19
https://public.kitware.com/Bug/file/5002/a5c3f059%2B0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch
patch a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch (1,469) 2013-12-05 09:46
https://public.kitware.com/Bug/file/5004/a5c3f059%2B0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch
patch a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch (1,401) 2013-12-19 14:14
https://public.kitware.com/Bug/file/5021/a5c3f059%2B0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch
Issue History
2012-12-13 15:55jujjylNew Issue
2012-12-13 16:15Brad KingRelationship addedrelated to 0013749
2012-12-18 08:02Brad KingRelationship addedduplicate of 0013511
2012-12-18 08:03Brad KingNote Added: 0031917
2012-12-18 08:03Brad KingStatusnew => resolved
2012-12-18 08:03Brad KingResolutionopen => duplicate
2012-12-18 08:20jujjylNote Added: 0031918
2012-12-18 08:20jujjylStatusresolved => feedback
2012-12-18 08:20jujjylResolutionduplicate => reopened
2012-12-18 09:43Brad KingRelationship replacedrelated to 0013511
2012-12-18 09:43Brad KingNote Added: 0031920
2012-12-18 09:43Brad KingPrioritynormal => none
2012-12-18 09:43Brad KingStatusfeedback => backlog
2012-12-18 09:43Brad KingResolutionreopened => open
2013-07-15 18:38Paul AnnettsNote Added: 0033543
2013-11-28 06:33Patrick R. GanstererRelationship addedhas duplicate 0014598
2013-11-30 13:53Moshe RubinNote Added: 0034613
2013-12-02 10:35Brad KingNote Added: 0034675
2013-12-03 03:43Moshe RubinNote Added: 0034687
2013-12-03 09:03Brad KingNote Added: 0034690
2013-12-03 09:04Brad KingNote Edited: 0034690bug_revision_view_page.php?bugnote_id=34690#r1327
2013-12-04 04:54Moshe RubinNote Added: 0034704
2013-12-04 07:59Brad KingNote Added: 0034705
2013-12-04 08:53Moshe RubinNote Added: 0034708
2013-12-04 09:19Brad KingFile Added: a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch
2013-12-04 09:24Brad KingNote Added: 0034709
2013-12-05 09:31Moshe RubinNote Added: 0034719
2013-12-05 09:34Moshe RubinNote Edited: 0034719bug_revision_view_page.php?bugnote_id=34719#r1331
2013-12-05 09:36Moshe RubinNote Edited: 0034719bug_revision_view_page.php?bugnote_id=34719#r1332
2013-12-05 09:38Moshe RubinNote Edited: 0034719bug_revision_view_page.php?bugnote_id=34719#r1333
2013-12-05 09:46Brad KingFile Added: a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch
2013-12-05 09:48Brad KingNote Added: 0034720
2013-12-05 11:11Patrick R. GanstererNote Added: 0034722
2013-12-05 11:17Brad KingNote Added: 0034723
2013-12-05 11:23Patrick R. GanstererNote Added: 0034725
2013-12-19 14:14Brad KingFile Added: a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch
2013-12-19 14:15Brad KingNote Added: 0034828
2014-09-12 09:41Brad KingNote Added: 0036786
2014-09-12 09:41Brad KingAssigned To => Brad King
2014-09-12 09:41Brad KingStatusbacklog => resolved
2014-09-12 09:41Brad KingResolutionopen => fixed
2014-09-12 09:41Brad KingFixed in Version => CMake 3.1
2014-09-12 09:41Brad KingTarget Version => CMake 3.1
2015-03-02 08:57Robert MaynardNote Added: 0038117
2015-03-02 08:57Robert MaynardStatusresolved => closed

Notes
(0031917)
Brad King   
2012-12-18 08:03   
Resolving as duplicate of 0013511.
(0031918)
jujjyl   
2012-12-18 08:20   
Hi, sorry for reopening, but apparently it is the only way to comment on an issue (or I did not find the proper button).

I don't think supporting Windows Phone 8 is a duplicate of supporting Windows 8 RT or Windows 8 RT for ARM. They have separate installable Visual Studio executables, separate project files (that differ by quite a lot) and separate compilers, so the support won't come automatically by implementing just support for one.

In summary, supporting WinPhone8, Win8RT for X86 and Win8RT for ARM can/could be done orthogonally as separate tasks, since they're separate toolchains.
(0031920)
Brad King   
2012-12-18 09:43   
Re 0013791:0031918: Okay, thanks for the clarification.
(0033543)
Paul Annetts   
2013-07-15 18:38   
I'm working on a patch for initial WP8 support (starting with static libraries).
(0034613)
Moshe Rubin   
2013-11-30 13:53   
Considering Brad King's comments in bug 0014598, I would like to propose the following fix. I have made the fix on my system and can now generate a VS solution file for cross-compiling a Windows Phone ARM binary target on a Windows 8 host.

The fix is in the "Modules\Platform\Windows-MSVC.cmake" file, starting on line 160:

<snippet>
if(MSVC_VERSION GREATER 1310)
  set(_RTC1 "/RTC1")
  set(_FLAGS_CXX " /GR /EHsc")
  # (30 Nov 2013): The following "if" added to prevent including windows system libraries if using an ARM generator
  if(NOT "${CMAKE_GENERATOR}" MATCHES "ARM")
      set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib")
  endif()
else()
  set(_RTC1 "/GZ")
  set(_FLAGS_CXX " /GR /GX")
  # (30 Nov 2013): The following "if" added to prevent including windows system libraries if using an ARM generator
  if(NOT "${CMAKE_GENERATOR}" MATCHES "ARM")
      set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib")
  endif()
endif()
</snippet>

The fix consists of adding an "if" statement to prevent adding the windows system libraries when using an ARM-related generator under Windows. The rational is that under Windows, compiling for ARM automatically precludes any Win32-related anything, rendering kernel32.lib etc. irrelevant.

Running my test emits the following CMake output:

<snippet>
--------------------------------------------
Using CMake 2.8.12-FIXED
--------------------------------------------
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
-- Check for working C compiler using: Visual Studio 11 ARM
-- Check for working C compiler using: Visual Studio 11 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11 ARM
-- Check for working CXX compiler using: Visual Studio 11 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/junk/TestProjects/CMakeArmRegression/Generated-2.8.12-FIXED
</snippet>

Would this fix be acceptable to the CMake team?
(0034675)
Brad King   
2013-12-02 10:35   
Re 0013791:0034613: The proposed solution is along the right lines and may be correct. However I'd like to determine if there is a better way to detect the ARM case which can work when using other generators. In the WinCE code path above the code in question we check the MSVC_${lang}_ARCHITECTURE_ID detected when determining the compiler id to look for ARM platforms. Would something similar work here?
(0034687)
Moshe Rubin   
2013-12-03 03:43   
Brad, I would like to test your idea, but am encountering what seems to be an undesired caching issue.

My version of CMake 2.8.12 is installed in the directory "C:\Program Files (x86)\CMake 2.8.12".

I attempted to modify the file "C:\Program Files (x86)\CMake 2.8.12\share\cmake-2.8\Modules\Platform\Windows-MSVC.cmake" by inserting some debugging statements at line 126:

<snippet>
[123] # default to Debug builds
[124] set(CMAKE_BUILD_TYPE_INIT Debug)
[125]
[126] #DEBUG-START
[127] message (STATUS "${lang}")
[128] message (STATUS "${MSVC_${lang}_ARCHITECTURE_ID}")
[129] #DEBUG-END
[130]
[131] if(WINCE)
[132] foreach(lang C CXX)
</snippet>

After deleting the previous Cmake-generated output folder, I reran my test case:

"C:\Program Files (x86)\CMake 2.8.12\bin\cmake.exe" ..\ -G "Visual Studio 11 ARM" -T "v110_wp80" --trace >..\foo 2>&1

Here are the relevant traced lines:

<snippet>
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(119): if(${MSVC_VERSION} GREATER 1599 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(120): set(MSVC_INCREMENTAL_DEFAULT ON )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(124): set(CMAKE_BUILD_TYPE_INIT Debug )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(126): if(WINCE )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(157): else()
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(158): if(MSVC_VERSION GREATER 1310 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(159): set(_RTC1 /RTC1 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(160): set(_FLAGS_CXX /GR /EHsc )
</snippet>

There are two strange things here:

(a) I expected to see the two message(...) outputs from lines 127-128 in the above trace, but did not.

(b) The statement "if(WINCE)", which used to be on line 126, was bumped to line 131 in the altered Windows-MSVC.cmake file. In the trace, however, it is still being read from line 126! It is as if CMake is opening the modified file (as evidenced by the path in the trace line and by checking with MS's ProcMon utility) but is reading the previous contents from some cache file.

Can you please tell me how I can make a change to the Windows-MSVC.cmake file that is picked up correctly and immediately by CMake? Can you also verify that I do not need to recompile the entire cmake.exe project for the *.cmake changes to be recognized?
(0034690)
Brad King   
2013-12-03 09:03   
(edited on: 2013-12-03 09:04)
Re 0013791:0034687: You are probably getting tripped up by the Windows Virtual Store feature:

http://blogs.msdn.com/b/chinmay_palei/archive/2011/01/16/windows-7-application-compatibility-issues-fix-centre.aspx [^]

Editing the file as an administrator should work. No you don't need to recompile for *.cmake changes.

(0034704)
Moshe Rubin   
2013-12-04 04:54   
Brad,

First, you were spot on about being tripped up by the Windows VirtualStore feature. I can now modify the Windows-MSVC.cmake file and see the changes immediately -- thanks! <g>

Second, I inserted message() statements in Windows-MSVC.cmake to print the values of ${MSVC_${lang}_ARCHITECTURE_ID} and other variables with the aim of using it to determine whether we should include Win32 system libraries or not:

<code>
#DEBUG-START
message (STATUS "\${lang} = \"${lang}\"")
message (STATUS "\${MSVC_\${lang}_ARCHITECTURE_ID} => " "\${MSVC_${lang}_ARCHITECTURE_ID}")
message (STATUS "\${MSVC_${lang}_ARCHITECTURE_ID} = \"${MSVC_${lang}_ARCHITECTURE_ID}\"")
message (STATUS "\${MSVC_C_ARCHITECTURE_ID} = \"${MSVC_C_ARCHITECTURE_ID}\"")
message (STATUS "\${MSVC_CXX_ARCHITECTURE_ID} = \"${MSVC_CXX_ARCHITECTURE_ID}\"")
#DEBUG-END

if(WINCE)
  foreach(lang C CXX)
    set(_MSVC_${lang}_ARCHITECTURE_FAMILY "${MSVC_${lang}_ARCHITECTURE_ID}")
    if(_MSVC_${lang}_ARCHITECTURE_FAMILY STREQUAL "THUMB")
      set(_MSVC_${lang}_ARCHITECTURE_FAMILY "ARM")
    elseif(_MSVC_${lang}_ARCHITECTURE_FAMILY MATCHES "^SH")
      set(_MSVC_${lang}_ARCHITECTURE_FAMILY "SHx")
    endif()
    string(TOUPPER "${_MSVC_${lang}_ARCHITECTURE_FAMILY}" _MSVC_${lang}_ARCHITECTURE_FAMILY_UPPER)
  endforeach()
  . . .
</code>

Here's the build output:

<build-output>
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
-- ${lang} = ""
-- ${MSVC_${lang}_ARCHITECTURE_ID} => ${MSVC__ARCHITECTURE_ID}
-- ${MSVC__ARCHITECTURE_ID} = ""
-- ${MSVC_C_ARCHITECTURE_ID} = "ARM"
-- ${MSVC_CXX_ARCHITECTURE_ID} = "ARM"
-- Check for working C compiler using: Visual Studio 11 ARM
-- Check for working C compiler using: Visual Studio 11 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11 ARM
-- Check for working CXX compiler using: Visual Studio 11 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/junk/TestProjects/CMakeArmRegression/Generated-2.8.12
</build-output>

This shows that ${lang} is the empty string (""), thereby preventing accessing ${MSVC_${lang}_ARCHITECTURE_ID} correctly. The variables ${MSVC_C_ARCHITECTURE_ID} and ${MSVC_CXX_ARCHITECTURE_ID}, however, are alive and kicking and can be used for our fix.

So the question is why is ${lang} not set. The only two places where <lang> is set is in:

<snippet>
Searching for: set(lang
CMake 2.8.12\share\cmake-2.8\Modules\FortranCInterface.cmake(227): set(lang C)
CMake 2.8.12\share\cmake-2.8\Modules\FortranCInterface.cmake(234): set(lang CXX)
Found 2 occurrence(s) in 1 file(s)
</snippet>

My test program has a single main.c file, so I would expect ${lang} to be set to "C". Here is my CMakeLists.txt file:

<code>
cmake_minimum_required(VERSION 2.6.0)
project(MyTest)
add_library(foo STATIC main.c)
</code>

Where then is ${lang} being set? Can we check either the C or the CXX form of variable for a value of "ARM"? Could the source file be in a different language (e.g., C#)? How would you like to implement the fix?
(0034705)
Brad King   
2013-12-04 07:59   
Re 0013791:0034704: The ${lang} is not a widely-visible variable. It is internal to Windows-MSVC.cmake. It is the loop parameter in the WINCE block and later the argument name of the __windows_compiler_msvc macro. The latter is invoked from Windows-MSVC-(C|CXX).cmake with the corresponding language name.
(0034708)
Moshe Rubin   
2013-12-04 08:53   
Duh <g>.

In this case we can certainly check ${MSVC_${lang}_ARCHITECTURE_ID} for "ARM". I'd like to suggest the following code (modify it any way you see fit):

<code>
if(WINCE)
  . . .
else()
  set(isARM "FALSE")
  foreach(lang C CXX)
    if(${MSVC_${lang}_ARCHITECTURE_ID} MATCHES "ARM")
      set(isARM "TRUE")
      break()
    endif()
  endforeach()
  
  if(NOT ${isArm})
      set(_PLATFORM_DEFINES "/DWIN32")
  endif()
  
  if(MSVC_VERSION GREATER 1310)
    set(_RTC1 "/RTC1")
    set(_FLAGS_CXX " /GR /EHsc")
    if(NOT ${isArm})
        set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib")
    endif()
  else()
    set(_RTC1 "/GZ")
    set(_FLAGS_CXX " /GR /GX")
    if(NOT ${isArm})
        set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib")
    endif()
  endif()

  if(MSVC_VERSION LESS 1310)
    set(_FLAGS_C " /Zm1000${_FLAGS_C}")
    set(_FLAGS_CXX " /Zm1000${_FLAGS_CXX}")
  endif()
endif()
</code>

Many thanks for holding my hand while investigating this problem <g>. It's been an honor contributing something back to the CMake project.
(0034709)
Brad King   
2013-12-04 09:24   
Re 0013791:0034708: Thanks. Try attached "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch" which does something similar to your change. Note I also check for the THUMB and SH architectures (is that correct?).

Note that this commit:

 VS: Detect MSVC compiler id on ARM toolchain
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4c04652 [^]

between 2.8.11 and 2.8.12 was likely the reason CMake started to detect the compiler id and load this file, as discussed in 0014598.

I'm not familiar with ARM development myself. I wonder why the author of that commit did not hit problems with linking of the Windows runtime libraries too. Is it only for specific platform toolsets (cmake -T option) that the Windows libraries should be excluded? Is it only for specific architectures?
(0034719)
Moshe Rubin   
2013-12-05 09:31   
(edited on: 2013-12-05 09:38)
Re 0013791:0034709: As far as I can ascertain, the THUMB and SHx processors are not relevant for Windows Phone, only for Windows CE.

Regarding the commit ("VS: Detect MSVC compiler id on ARM toolchain"), I checked the head version of CMakeDetermineCompilerId.cmake (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=HEAD [^]) but could not see the lines committed. The head version shows:

<code>
136 if("${id_platform}" STREQUAL "Itanium")
137 set(id_platform ia64)
138 endif()
</code>

The commit shows the lines (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=e4c046521f1da9cee44833d88320d7551719059b [^]):

<code>
129 if("${id_arch}" STREQUAL "x64")
130 set(id_machine_10 MachineX64)
131 elseif("${id_arch}" STREQUAL "Itanium")
132 set(id_machine_10 MachineIA64)
133 set(id_arch ia64)
134 elseif("${id_arch}" STREQUAL "ARM")
135 set(id_machine_10 MachineARM)
136 else()
137 set(id_machine_6 x86)
138 set(id_machine_10 MachineX86)
139 endif()
</code>

Why are they so different?

I cannot explain why the committer did not experience the problems I'm experiencing. Removing the -T platform toolset from the command line causes the build to fail. I believe that using an ARM generator implicitly implies that no Win32 system DLLs will be used at all.

(0034720)
Brad King   
2013-12-05 09:48   
Re 0013791:0034719: Later another commit dropped use of the target machine from compiler id detection altogether:

 VS10: Do not set the TargetMachine when detecting the compiler
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=60e568cf [^]

IIUC this also would have fixed compiler id detection under ARM by itself.

If THUMB and SHx are only for WinCE then we need only to check for "ARM" as you originally suggested.
Please try "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch".
(0034722)
Patrick R. Gansterer   
2013-12-05 11:11   
Do Windows Phone 8 support X86 architecture? If yes: How do you ensure that the system libraries do not get linked for x86 phones?
At the moment this seams to get into an direction which makes the MSVC stuff even harder to understand if we mix CPU architecture with system API. :-(
What about detecting the system API from the target platform (?) and introduce a new variable like WINRT, we can check then instead of abusing the CPU architecture for that?
(0034723)
Brad King   
2013-12-05 11:17   
Re 0013791:0034722: Thanks Patrick. That makes sense to me but I'm not familiar with any embedded target platforms with MSVC tools so I'm fully dependent on contributors to work this out. What do others think?
(0034725)
Patrick R. Gansterer   
2013-12-05 11:23   
Re 0013791:0034723: I'm familiar with WinCE as you might know, but haven't done anything with the other "embedded" platforms of MSVC for now. I'd like to dive into it and maybe implement it, but I'm short of time at the moment. :-(
(0034828)
Brad King   
2013-12-19 14:15   
Since none of us seems to understand the relationship among WinCE, WinRT, Windows Phone 8, ARM, etc. the simplest patch to solve the immediate issue is something like "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch" that just drops the system libs for the VS ARM generator. Please try it out.
(0036786)
Brad King   
2014-09-12 09:41   
The development version of CMake now supports running with

 cmake .. -G "Visual Studio 11 2012" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.0

or

 cmake .. -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.1

to generate project files for Windows Phone. Nightly binaries are available here:

 http://www.cmake.org/files/dev/?C=M;O=D [^]

If you try it, please bring feedback to the cmake-developers mailing list:

 http://www.cmake.org/mailman/listinfo/cmake-developers [^]
(0038117)
Robert Maynard   
2015-03-02 08:57   
Closing resolved issues that have not been updated in more than 4 months.