MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013511CMakeCMakepublic2012-09-03 10:152015-03-02 08:57
ReporterSergey Yakovlev 
Assigned ToBrad King 
PriorityhighSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSWindows 8 RTM x64OS Version
Product VersionCMake 2.8.9 
Target VersionCMake 3.1Fixed in VersionCMake 3.1 
Summary0013511: Add support for WinRT platforms and "metro" apps
DescriptionEnvironment:
* Windows 8 RTM x64
* CMake 2.8.9
* Visual Studio 2012 RTM 11.0.50727.1 RTMEL

Attempt to use "Visual Studio 11 ARM" generator leads to below error:
-- 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 -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTes
tCCompiler.cmake:61 (message):
  The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
  11.0/VC/bin/cl.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/Users/MyUser/Desktop/MyProject/CMakeFiles/CMakeTmp



  Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com
  CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec923234006



  Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.50727.1.

  Copyright (C) Microsoft Corp. All rights reserved.

  ------ Build started: Project: cmTryCompileExec923234006, Configuration:
  Debug ARM ------

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\ARM\PlatformToolsets\v110\Micr
osoft.Cpp.ARM.v110.targets(36,5):
  error MSB8022: Compiling Desktop applications for the ARM platform is not
  supported.

  ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
  ==========





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:281 (project)


-- Configuring incomplete, errors occurred!
Steps To Reproduce
Additional InformationVS2012 RTM doesn't allow to build desktop projects for ARM platform.

It seems that all you need to fix this issue is adding <AppContainerApplication>true</AppContainerApplication> to <PropertyGroup> section of test project (CMAKE_TRY_COMPILE.sln).

TagsNo tags attached.
Relationships
related to 0013077closed Brad King Generator for Visual Studio 11 ARM 
related to 0012930closed Brad King [patch] CMake does not support Visual Studio 11 WinRT project type 
has duplicate 0013749closed  Cannot target Windows 8 RT from CMake without workarounds. 
has duplicate 0013498closed  CMake does not fully support Visual Studio 11 WinRT project type 
related to 0013791closed Brad King CMake does not support generating projects for Windows Phone 8. 
related to 0014129closed Brad King CMakeDetermineCompilerId.cmake is broken for VS 2011/2012 ARM targets 
related to 0014596closed  No PackageCertificateKeyFile tag 
Attached Filespatch AppContainerApplication.patch (737) 2012-12-14 00:56
https://public.kitware.com/Bug/file/4592/AppContainerApplication.patch
patch AppxManifest.patch (577) 2012-12-14 01:58
https://public.kitware.com/Bug/file/4593/AppxManifest.patch
patch TryCompile.patch (735) 2012-12-17 23:58
https://public.kitware.com/Bug/file/4597/TryCompile.patch
patch VS11ArmPatches.patch (10,485) 2013-04-15 09:35
https://public.kitware.com/Bug/file/4736/VS11ArmPatches.patch
patch WinRTon2.8.12.patch (3,499) 2013-11-09 10:02
https://public.kitware.com/Bug/file/4943/WinRTon2.8.12.patch
patch WinRTon2.8.12.v2.patch (3,953) 2013-11-11 20:38
https://public.kitware.com/Bug/file/4946/WinRTon2.8.12.v2.patch
patch WinRTon2.8.12.1.v3.patch (6,685) 2013-11-23 10:45
https://public.kitware.com/Bug/file/4960/WinRTon2.8.12.1.v3.patch
patch WinRTon2.8.12.1.v4.patch (9,056) 2013-11-25 10:15
https://public.kitware.com/Bug/file/4965/WinRTon2.8.12.1.v4.patch
patch WinRTon2.8.12.1.v5.patch (11,116) 2013-11-26 10:19
https://public.kitware.com/Bug/file/4970/WinRTon2.8.12.1.v5.patch
patch 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.patch (24,228) 2014-01-31 01:49
https://public.kitware.com/Bug/file/5054/0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.patch
patch 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v2.patch (24,293) 2014-01-31 23:10
https://public.kitware.com/Bug/file/5055/0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v2.patch
patch 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch (11,552) 2014-02-05 01:43
https://public.kitware.com/Bug/file/5059/0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
patch 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch (7,190) 2014-02-05 01:43
https://public.kitware.com/Bug/file/5060/0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
patch 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch (3,521) 2014-02-05 01:44
https://public.kitware.com/Bug/file/5061/0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
patch 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch (10,491) 2014-02-08 22:15
https://public.kitware.com/Bug/file/5064/0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
patch 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch (7,039) 2014-02-08 22:15
https://public.kitware.com/Bug/file/5065/0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
patch 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch (2,413) 2014-02-08 22:16
https://public.kitware.com/Bug/file/5066/0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
patch 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch (10,975) 2014-03-19 21:30
https://public.kitware.com/Bug/file/5098/0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
patch 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch (6,907) 2014-03-19 21:30
https://public.kitware.com/Bug/file/5099/0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
patch 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch (2,414) 2014-03-19 21:30
https://public.kitware.com/Bug/file/5100/0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
Issue History
Date ModifiedUsernameFieldChange
2012-09-03 10:15Sergey YakovlevNew Issue
2012-09-03 10:21Brad KingRelationship addedrelated to 0012930
2012-09-03 10:22Brad KingRelationship addedrelated to 0013077
2012-09-03 10:22Brad KingRelationship deletedrelated to 0012930
2012-09-03 10:25Brad KingRelationship addedrelated to 0012930
2012-09-03 10:27Brad KingNote Added: 0030821
2012-09-03 10:27Brad KingStatusnew => backlog
2012-09-03 10:27Brad KingTarget Version => CMake 2.8.10
2012-10-18 11:18David ColeNote Added: 0031271
2012-10-18 11:18David ColeTarget VersionCMake 2.8.10 => CMake 2.8.11
2012-11-13 22:45Yan Cheng CHEOKNote Added: 0031547
2012-11-14 07:20Brad KingNote Added: 0031551
2012-11-28 08:33Brad KingRelationship addedrelated to 0013749
2012-11-28 08:36Brad KingRelationship addedrelated to 0013498
2012-11-28 08:42Brad KingNote Added: 0031737
2012-12-14 00:56Minmin GongFile Added: AppContainerApplication.patch
2012-12-14 00:58Minmin GongNote Added: 0031882
2012-12-14 01:58Minmin GongFile Added: AppxManifest.patch
2012-12-14 01:59Minmin GongNote Added: 0031884
2012-12-14 08:28Brad KingNote Added: 0031890
2012-12-17 00:08Minmin GongNote Added: 0031904
2012-12-17 09:40Brad KingNote Added: 0031907
2012-12-17 23:58Minmin GongFile Added: TryCompile.patch
2012-12-18 00:02Minmin GongNote Added: 0031910
2012-12-18 07:30Intrepid SoldierNote Added: 0031912
2012-12-18 07:51Brad KingNote Deleted: 0031912
2012-12-18 07:55Brad KingNote Added: 0031913
2012-12-18 07:58Brad KingNote Added: 0031914
2012-12-18 07:58Brad KingSeveritymajor => feature
2012-12-18 07:58Brad KingSummaryCannot use with VS 2012 RTM for ARM platform => Add support for WinRT platforms and "metro" apps
2012-12-18 07:58Brad KingTarget VersionCMake 2.8.11 =>
2012-12-18 07:59Brad KingRelationship replacedhas duplicate 0013498
2012-12-18 08:01Brad KingRelationship replacedhas duplicate 0013749
2012-12-18 08:02Brad KingRelationship addedhas duplicate 0013791
2012-12-18 09:43Brad KingRelationship replacedrelated to 0013791
2013-04-09 11:00squirrelfmFile Added: CMakeTestCXXCompiler.cmake.patch
2013-04-09 11:01squirrelfmFile Added: cmCoreTryCompile.cxx.patch
2013-04-09 11:03squirrelfmFile Added: cmCoreTryCompile.h.patch
2013-04-09 11:03squirrelfmFile Added: cmProjectCommand.cxx.patch
2013-04-09 11:03squirrelfmFile Added: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-09 11:39squirrelfmNote Added: 0032787
2013-04-09 13:14Brad KingFile Deleted: CMakeTestCXXCompiler.cmake.patch
2013-04-09 13:14Brad KingFile Deleted: cmCoreTryCompile.cxx.patch
2013-04-09 13:14Brad KingFile Deleted: cmCoreTryCompile.h.patch
2013-04-09 13:15Brad KingFile Deleted: cmProjectCommand.cxx.patch
2013-04-09 13:15Brad KingFile Deleted: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-10 12:08squirrelfmFile Added: CMakeTestCXXCompiler.cmake.patch
2013-04-10 12:08squirrelfmFile Added: cmCoreTryCompile.cxx.patch
2013-04-10 12:08squirrelfmFile Added: cmCoreTryCompile.h.patch
2013-04-10 12:10squirrelfmFile Added: cmLocalGenerator.cxx.patch
2013-04-10 12:10squirrelfmFile Added: cmLocalGenerator.h.patch
2013-04-10 12:10squirrelfmFile Added: cmProjectCommand.cxx.patch
2013-04-10 12:15squirrelfmFile Added: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-12 08:39Brad KingFile Deleted: CMakeTestCXXCompiler.cmake.patch
2013-04-12 08:39Brad KingFile Deleted: cmCoreTryCompile.cxx.patch
2013-04-12 08:39Brad KingFile Deleted: cmCoreTryCompile.h.patch
2013-04-12 08:39Brad KingFile Deleted: cmLocalGenerator.cxx.patch
2013-04-12 08:39Brad KingFile Deleted: cmLocalGenerator.h.patch
2013-04-12 08:39Brad KingFile Deleted: cmProjectCommand.cxx.patch
2013-04-12 08:39Brad KingFile Deleted: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-12 08:40Brad KingNote Added: 0032813
2013-04-15 09:35squirrelfmNote Added: 0032833
2013-04-15 09:35squirrelfmFile Added: VS11ArmPatches.patch
2013-04-15 09:35squirrelfmNote Deleted: 0032833
2013-04-15 09:41squirrelfmNote Added: 0032834
2013-04-15 10:10Brad KingNote Added: 0032836
2013-04-28 18:18Martell MaloneNote Added: 0032952
2013-04-28 18:25Martell MaloneNote Edited: 0032952bug_revision_view_page.php?bugnote_id=32952#r1145
2013-04-28 18:28Martell MaloneNote Edited: 0032952bug_revision_view_page.php?bugnote_id=32952#r1146
2013-04-28 18:32Martell MaloneNote Edited: 0032952bug_revision_view_page.php?bugnote_id=32952#r1147
2013-04-28 18:41Martell MaloneNote Edited: 0032952bug_revision_view_page.php?bugnote_id=32952#r1148
2013-05-07 09:35Brad KingRelationship addedrelated to 0014129
2013-06-12 02:03ixSciNote Added: 0033275
2013-06-12 02:05ixSciNote Edited: 0033275bug_revision_view_page.php?bugnote_id=33275#r1185
2013-09-03 09:16Daniel PfeiferNote Added: 0033777
2013-11-09 10:02Minmin GongFile Added: WinRTon2.8.12.patch
2013-11-09 10:11Minmin GongNote Added: 0034429
2013-11-11 20:38Minmin GongFile Added: WinRTon2.8.12.v2.patch
2013-11-11 20:38Minmin GongNote Added: 0034431
2013-11-12 14:04Brad KingNote Added: 0034438
2013-11-12 14:05Brad KingNote Added: 0034439
2013-11-23 10:45Minmin GongFile Added: WinRTon2.8.12.1.v3.patch
2013-11-23 10:51Minmin GongNote Added: 0034525
2013-11-23 10:51Minmin GongNote Edited: 0034525bug_revision_view_page.php?bugnote_id=34525#r1320
2013-11-25 10:15Minmin GongFile Added: WinRTon2.8.12.1.v4.patch
2013-11-25 10:22Minmin GongNote Added: 0034551
2013-11-26 09:24Brad KingRelationship addedrelated to 0014596
2013-11-26 10:19Minmin GongFile Added: WinRTon2.8.12.1.v5.patch
2013-11-26 10:22Minmin GongNote Added: 0034568
2013-11-26 10:33Brad KingNote Added: 0034569
2014-01-31 01:49Minmin GongFile Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.patch
2014-01-31 01:57Minmin GongNote Added: 0035014
2014-01-31 07:51Patrick R. GanstererNote Added: 0035015
2014-01-31 23:10Minmin GongFile Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v2.patch
2014-01-31 23:18Minmin GongNote Added: 0035016
2014-02-01 05:41Patrick R. GanstererNote Added: 0035017
2014-02-01 23:38Minmin GongNote Added: 0035019
2014-02-05 01:43Minmin GongFile Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
2014-02-05 01:43Minmin GongFile Added: 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
2014-02-05 01:44Minmin GongFile Added: 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
2014-02-05 02:09Minmin GongNote Added: 0035038
2014-02-07 10:44Brad KingNote Added: 0035054
2014-02-08 22:15Minmin GongFile Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
2014-02-08 22:15Minmin GongFile Added: 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
2014-02-08 22:16Minmin GongFile Added: 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
2014-02-08 22:19Minmin GongNote Added: 0035059
2014-02-11 10:44Brad KingNote Added: 0035093
2014-02-14 02:14Minmin GongNote Added: 0035105
2014-02-14 13:54Brad KingNote Added: 0035111
2014-02-15 02:06Minmin GongNote Added: 0035113
2014-02-17 08:49Brad KingNote Added: 0035122
2014-02-17 11:38Brad KingNote Added: 0035134
2014-02-18 00:10Minmin GongNote Added: 0035137
2014-03-19 21:29Minmin GongNote Added: 0035441
2014-03-19 21:30Minmin GongFile Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
2014-03-19 21:30Minmin GongFile Added: 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
2014-03-19 21:30Minmin GongFile Added: 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
2014-03-21 10:34Brad KingNote Added: 0035464
2014-03-25 06:06Minmin GongNote Added: 0035505
2014-09-12 09:42Brad KingNote Added: 0036787
2014-09-12 09:42Brad KingNote Edited: 0036787bug_revision_view_page.php?bugnote_id=36787#r1569
2014-09-12 09:43Brad KingAssigned To => Brad King
2014-09-12 09:43Brad KingStatusbacklog => resolved
2014-09-12 09:43Brad KingResolutionopen => fixed
2014-09-12 09:43Brad KingFixed in Version => CMake 3.1
2014-09-12 09:43Brad KingTarget Version => CMake 3.1
2015-03-02 08:57Robert MaynardNote Added: 0038118
2015-03-02 08:57Robert MaynardStatusresolved => closed

Notes
(0030821)
Brad King   
2012-09-03 10:27   
ARM support was added by a contributor through 0013077.

Please propose a patch adding
<AppContainerApplication>true</AppContainerApplication> under the proper conditions. Be sure it does not conflict with <WindowsAppContainer> from issue 0012930.
(0031271)
David Cole   
2012-10-18 11:18   
This bug is awaiting a response to Brad's latest note from the reporter. Moving target version from 2.8.10 to 2.8.11 since we are about to do the 2nd release candidate for 2.8.10 already...
(0031547)
Yan Cheng CHEOK   
2012-11-13 22:45   
Hi, any idea when will CMake 2.8.11 be released with this bug being fixed? Thx.
(0031551)
Brad King   
2012-11-14 07:20   
Re 0013511:0031547: No further progress will be made on this issue until a response is provided to my request in 0013511:0030821.
(0031737)
Brad King   
2012-11-28 08:42   
Issues 0013511, 0013498, 0013749 are all asking for WinRT support in some form. The existing CMake features for it were contributed by a user in 0012930. No progress is being made on these issues by upstream CMake developers. Please propose patches.

There should be no new keyword arguments to add_executable. Any information needed can be added to a target with the "set_property(TARGET ...)" command.
(0031882)
Minmin Gong   
2012-12-14 00:58   
I've created a patch based on cmake 2.8.10.2 to add <AppContainerApplication>true</AppContainerApplication> correctly. My question is, how to deliver the VS_WINRT_EXTENSIONS to CMAKE_TRY_COMPILE? In my tracing, when generating CMAKE_TRY_COMPILE, the VS_WINRT_EXTENSIONS is false, so this problem still there.
(0031884)
Minmin Gong   
2012-12-14 01:59   
Another AppxManifest.patch fix the WinRT's new file type appxmanifest.
(0031890)
Brad King   
2012-12-14 08:28   
Thanks for working on patches.

The try_compile command generates test project CMake code in cmCoreTryCompile.cxx in the cmCoreTryCompile::TryCompileCode method. See lines like:

    fprintf(fout, "ADD_EXECUTABLE(%s \"%s\")\n", targetName, source.c_str());
    fprintf(fout, "TARGET_LINK_LIBRARIES(%s ${LINK_LIBRARIES})\n",targetName);

that generate the CMake code. Just above those there is a bunch of logic to pass some platform-dependent information into the test project's CMake invocation. Somehow we need the outer project invoking try_compile to pass information through here.

What kinds of try_compile operations need to be supported? All of CMake's standard checks?

Is VS_WINRT_EXTENSIONS something that should be set on all targets and/or try_compile calls within a project or only some of them?
(0031904)
Minmin Gong   
2012-12-17 00:08   
When try_compile checks the ARM compiler, it returns fail because VC's ARM compiler can't compile a exe project without <AppContainerApplication>true</AppContainerApplication>. So VS_WINRT_EXTENSIONS should be set to all targets if it's for WinRT project.
(0031907)
Brad King   
2012-12-17 09:40   
Re 0013511:0031904: If the ARM toolchain cannot compile anything without
AppContainerApplication then wouldn't
VS_WINRT_EXTENSIONS need to be set on *every* target in the project? Perhaps it should be a more global setting rather than per-target. That global setting could then be propagated by cmCoreTryCompile into the test projects.
(0031910)
Minmin Gong   
2012-12-18 00:02   
The TryCompile.patch can successfully add the VS_WINRT_EXTENSIONS to try compile. But it's still failed because the testCCompiler.c. In a metro application, the int main() is not valid. Instead, it requires:
[Platform::MTAThread]
int main(Platform::Array<Platform::String^>^ /*args*/)
{
  ...
}
That should be patched too.

You are right. The VS_WINRT_EXTENIONS need to be set on every exe target. I agree that it better to be a global setting.
(0031913)
Brad King   
2012-12-18 07:55   
Re 0013511:0031910: The main() may come from many different places. Each Check*.cmake module generates its own test source file. They will all need to be patched to be aware of how to write main().
(0031914)
Brad King   
2012-12-18 07:58   
Changing to feature request because this is really about adding support for a new platform.
(0032787)
squirrelfm   
2013-04-09 11:39   
I've created a patches based on cmake 2.8.10.2 and http://public.kitware.com/Bug/view_user_page.php?id=4505. [^]
1)In CmakeTestCCompiler we can't use C++\CX extension for correct main() so this test must be disabled. So I’ve disabled CmakeTestCCompiler and only CmakeTestCxxCompiler test will run now.
2)In CmakeTestCXXCompiler at generating testCXXCompiler.cxx I identified 2 cases:
if generator is "Visual Studio 11 ARM" test creating the "special" main(), else "standart" main()
3)Also I’ve removed for ARM platform 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;
4)In ARM platform always required Win Store App Support is true, so I've added <AppContainerApplication> for it case, too, and not just when set properties "VS_WINRT_EXTENSIONS"
5)In cmCoreTryCompile I've added creating appxmanifest if we use VS 11 ARM generator
(0032813)
Brad King   
2013-04-12 08:40   
Re 0013511:0032787: Please use "git commit" locally and then "git format-patch HEAD~1.." to construct a single patch file with a commit message.
(0032834)
squirrelfm   
2013-04-15 09:41   
I've uploaded patch with following changes:
1)In CmakeTestCCompiler we can't use C++\CX extension for correct main() so this test must be disabled. So I’ve disabled CmakeTestCCompiler and only CmakeTestCxxCompiler test will run now.
2)In CmakeTestCXXCompiler at generating testCXXCompiler.cxx I identified 2 cases:
if generator is "Visual Studio 11 ARM" test creating the "special" main(), else "standart" main()
3)Also I’ve removed for ARM platform 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;
4)In ARM platform always required Win Store App Support is true, so I've added <AppContainerApplication> for it case, too, and not just when set properties "VS_WINRT_EXTENSIONS"
5)In cmCoreTryCompile I've added creating appxmanifest if we use VS 11 ARM generator
6)In cmVisualStudioTargetGenerator.cxx absolute pathes were replaced by relative.
7) Added method IsVs11CurrentGlobalGenerator() in cmLocalGenerator.cxx
(0032836)
Brad King   
2013-04-15 10:10   
Re 0013511:0032834: Thanks for working on this.

I'd appreciate it if others following this thread could test "VS11ArmPatches.patch" as I have no experience with WinRT, Win8, or ARM development.

I can however comment on the implementation in the patch. Code like

 if (this->Makefile->GetLocalGenerator()->isVS11ARMCurrentGlobalGenerator())

that appears in otherwise general-purpose locations is too specific. Instead the different behaviors should be abstracted behind a virtual method in the cmGlobalGenerator API.

Also, there are a lot of other places that generate main() signatures for try_compile projects. Run

 git grep '\<main\>' -- Modules

at a Git prompt from the top of the source tree to see some of them. Rather than teaching all of them individually about the different possible main() signatures we need to design a way to abstract out generation of program entry points for sources used with try_compile.
(0032952)
Martell Malone   
2013-04-28 18:18   
(edited on: 2013-04-28 18:41)
Re 0013511:0032834 This is some good progress :)
I agree with 0013511:0032836 though the function should be created elsewhere.

So I've changed
GetLocalGenerator()->isVS11ARMCurrentGlobalGenerator() to
GetLocalGenerator()->GetGlobalGenerator()->GetName() and then done string compares.

I believe that we are looking at this the wrong way though(explained further below) because you patch removes "3) default-added linking"

What happens if we try to create a metro app for x86 or x64 platforms?
We still want to stop the linking of these libraries of course

I've adjusted your patch to take this into account and also for packing appx packages

<None Include="SmallLogo.png" />
changes to
<Image Include="SmallLogo.png" />

and for shaders

<None Include="PixelShader.hlsl"/>
changes to
<FxCompile Include="PixelShader.hlsl"><ShaderType>Pixel</ShaderType></FxCompile>

Saying Pixel or Vertex where needed

It's needed to create a package ;)

Here is the patch

gist.github.com/martell/5478621

It should work on the latest git and I've tested it and it works to generate a winrt cocos2dx game :)

The only thing left is to get winmd files built when building a static library using c++/cx code

My current work around is to build a shared library also to get that file

The only other thing left is to change this over to a new VS11 generator (because of the new differences) instead of VS10 if you guys over at kitware want that?

I said above we are looking at this the wrong way. What I meant by this is that Visual Studio 11 ARM is not another platform Metro is the platform. I'm not 100% certain on this but what happens if Microsoft decide to support desktop apps for arm? We have just forced cmake to use appx in the generator.

We should be thinking of Metro as another platform and not ARM.
We should also be able to generate a single solution for multiple architectures but I don't think cmake is designed with that in mind? I could be wrong though.

Microsoft have been trolling with their new standards :P
(0033275)
ixSci   
2013-06-12 02:03   
(edited on: 2013-06-12 02:05)
Also XAML files should be treated differently. Now they are added as None element but should be added as Page element
And main XAML file should be added with ApplicationDefinition element
(0033777)
Daniel Pfeifer   
2013-09-03 09:16   
There seems to be some misinformation here.

Building for ARM does *not* require C++/CX and changing the signature of main() is *not* needed.

All it needs is the "<WindowsAppContainer>true</WindowsAppContainer>" setting for Visual Studio projects or -DWINAPI_FAMILY=WINAPI_PARTITION_APP on the command line.

C++/CX (enabled by the /ZW flag) is optional. There is no need to depend on C++/CX for try_compile().
(0034429)
Minmin Gong   
2013-11-09 10:11   
I've uploaded a new patch WinRTon2.8.12.patch based on cmake 2.8.12. It contains 3 modifications to Source/cmVisualStudio10TargetGenerator.cxx.
1. Add "<AppContainerApplication>true</AppContainerApplication>" when VS_WINRT_EXTENSIONS is on.
2. Recognize AppxManifest file type.
3. Add "<DeploymentContent Condition="...">true</DeploymentContent>" or "<ExcludedFromBuild Condition="...">true</ExcludedFromBuild>" to a <None> type file.

The 1st and 2nd ones are combined from the AppContainerApplication.patch and AppxManifest.patch. However, the 3rd one is a little tricky. In WinRT project, a content file need to be marked as DeploymentContent for deploying. But at least in my project, some files are deployed only in debug configuration, some in release configuration. Currently with this patch, I can achieve this by defining some special COMPILE_DEFINITIONS:

SET(DEBUG_CONTENT_FILES
    foo${CMAKE_DEBUG_POSTFIX}.dll)
SET(RELEASE_CONTENT_FILES
    foo.dll)

SET_SOURCE_FILES_PROPERTIES(${DEBUG_CONTENT_FILES}
    PROPERTIES
    COMPILE_DEFINITIONS_DEBUG "-DCONTENT"
    COMPILE_DEFINITIONS_RELEASE "-DEXCLUDED"
    COMPILE_DEFINITIONS_RELWITHDEBINFO "-DEXCLUDED"
    COMPILE_DEFINITIONS_MINSIZEREL "-DEXCLUDED")
SET_SOURCE_FILES_PROPERTIES(${RELEASE_CONTENT_FILES}
    PROPERTIES
    COMPILE_DEFINITIONS_DEBUG "-DEXCLUDED"
    COMPILE_DEFINITIONS_RELEASE "-DCONTENT"
    COMPILE_DEFINITIONS_RELWITHDEBINFO "-DCONTENT"
    COMPILE_DEFINITIONS_MINSIZEREL "-DCONTENT")

But I'm sure there would be a better way to do this. Any ideas?
(0034431)
Minmin Gong   
2013-11-11 20:38   
Updated my patch. Add VS2013 with Win 8.1 app type support.
(0034438)
Brad King   
2013-11-12 14:04   
Re 0013511:0033777: Thanks. The C++/CX behavior of VS_WINRT_EXTENSIONS is incorrect IMO and should be removed. I'm not sure what level of adoption this has but it is tempting to just change it with no attempt at compatibility. However, perhaps this doesn't matter because we need a more general way of enabling WinRT support. It needs to be done not at the target level but at a higher level such that CMake can know to apply it to try_compile calls and such.

Re 0013511:0034429: I think you need a dedicated source file property to specify the DeploymentContent setting. It can be made per-configuration by allowing use of generator expressions, e.g. "$<CONFIG:Debug>".
(0034439)
Brad King   
2013-11-12 14:05   
I suggest raising WinRT support for general discussion on the user's list:

 http://www.cmake.org/mailman/listinfo/cmake [^]

to see what other input can be collected.
(0034525)
Minmin Gong   
2013-11-23 10:51   
The 3) of 0013511:0034429 is too specific, so now I'm using ADD_CUSTOM_COMMAND and INSTALL to achieve the same goal. In my updated patch WinRTon2.8.12.1.v3.patch, that part is removed. "Deploy.0" in .sln is added for deploy WinRT apps by default.

With this patch, although some manual operations is required (build->install->deploy), at least my apps can work with cmake well.
(0034551)
Minmin Gong   
2013-11-25 10:22   
It turns out that with ADD_CUSTOM_COMMAND and INSTALL, it works well in Visual Studio. But it fails in MSBuild. The MSBuild requires content files be a part of output of the project. So I implemented this by following your advice in http://www.cmake.org/Bug/view.php?id=13511#c34438. [^] In my updated patch WinRTon2.8.12.1.v4.patch, a dedicated boolean source file property "VS_WINRT_CONTENT" is used for deployment setting. Generator expressions is also supported. The usage of VS_WINRT_CONTENT looks like this:
SET_SOURCE_FILES_PROPERTIES(${CONTENT_FILES}
    PROPERTIES
    VS_WINRT_CONTENT 1)
SET_SOURCE_FILES_PROPERTIES(${DEBUG_CONTENT_FILES}
    PROPERTIES
    VS_WINRT_CONTENT $<CONFIG:Debug>)
SET_SOURCE_FILES_PROPERTIES(${RELEASE_CONTENT_FILES}
    PROPERTIES
    VS_WINRT_CONTENT $<OR:$<CONFIG:Release>,$<CONFIG:RelWithDebInfo>,$<CONFIG:MinSizeRel>>)
(0034568)
Minmin Gong   
2013-11-26 10:22   
The patch is updated to V5. Fix an issue in DeploymentContent part. The PackageCertificateKeyFile tag patch from 0014596 is merged.
(0034569)
Brad King   
2013-11-26 10:33   
Re 0013511:0034568: Okay, thanks. Please rebase this on our Git 'master' branch, write a full commit message explaining the change, and post a patch created by "git format-patch". Then look at these instructions:

 http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer [^]

and post the patch to the mailing list for broader discussion.
(0035014)
Minmin Gong   
2014-01-31 01:57   
I've updated my patch with ARM support, inspired by http://www.cmake.org/Bug/view.php?id=13511#c32952 [^] and http://www.cmake.org/Bug/view.php?id=13511#c33777. [^] And it's based on Git master branch.

Daniel's information is correct. "Building for ARM does *not* require C++/CX and changing the signature of main() is *not* needed." So what we need to do is modify Modules\CompilerId\VS-10.vcxproj.in a little to add win store tag in. Then the compiler determine and testCXX works.

Another thing is for utility projects, such as ALL_BUILD and ZERO_CHECKS. They can't be in win store or ARM configuration. They are changed to Win32 by default.

I've also posted a mail to CMake mailing list.
(0035015)
Patrick R. Gansterer   
2014-01-31 07:51   
Using >>CMAKE_GENERATOR MATCHES "ARM"<< is a clear no go, since it conflicts with Windows CE SDKs which contain ARM in their name (e.g. "STANDARDSDK_500 (ARMV4I)"). Please don't mix the target architecture (x86, x86_64, ARM) with the OS API (Win32, WinRT). What can we do if MS decides to port WindowsNT to the ARM platform in the future?
I'd like to see something like an WINRT variable equal to the WINCE variable, which can be checked in the projects too.

Also the changing the platforname back to Win32 seams like a big hack to me. I'd create a separate patch for the utility targets, if they are not required for every project. That would make discussing the basic WinRT support easier.
(0035016)
Minmin Gong   
2014-01-31 23:18   
I've updated my patch based on your comment. The CMAKE_GENERATOR MATCHES "ARM" is modified to CMAKE_GENERATOR MATCHES "Visual Studio ([0-9]+) ARM" to rule out the CE generator.

I agree that WinRT is at platform level, like WinCE. And yes, it's a hack to change the platform name. Utility target (and maybe also GLOBAL_TARGET) should have a better way to indicate the platform. When will your patch available in cmake?
(0035017)
Patrick R. Gansterer   
2014-02-01 05:41   
I'd like to see the "WinRT" or "Metro" in the generator name. What would you call the native ARM generator later if Microsoft releases a ARM version of Windows with Win32 API?

Is the support for utilities required for _every_ project? If not please create a separate patch.

If possible please split the patch into smaller individual patches. That makes review easier.

Please add a WINRT variable (like WINCE) in Windows-MSVC.cmake to avoid checking the generator name more than once.

What do you mean with "When will your patch available in cmake?"? I'm not working on this.

One other point: Please use the CMake coding style for your changes.
(0035019)
Minmin Gong   
2014-02-01 23:38   
> I'd like to see the "WinRT" or "Metro" in the generator name. What would you call the native ARM generator later if Microsoft releases a ARM version of Windows with Win32 API?

I see. Yes, generator name with WinRT is a better than only VS_WINRT_EXTENSION and ARM. VS_WINRT_EXTENSION is on compiler option level, but WinRT is on platform level. They are actually orthogonal.

> Is the support for utilities required for _every_ project? If not please create a separate patch.

ARM configuration in MSVC doesn't support utility type. So it must be in host system CPU's configuration. I'm curious how WinCE generator handles this.

> If possible please split the patch into smaller individual patches. That makes review easier.

Will do.

> What do you mean with "When will your patch available in cmake?"? I'm not working on this.

Sorry, I had some misunderstanding before.


Now I'm working on a "WinRT as platform" patch. It can be more simple and easy than current one.
(0035038)
Minmin Gong   
2014-02-05 02:09   
I've updated my patch to V3. In this version, the WinRT is considered as a platform. Generators with "WinRT" suffix, such as "Visual Studio 12 WinRT", "Visual Studio 12 ARM WinRT", can be used to generate a WinRT targeting MSVC project. CMAKE_VS_WINRT_VERSION and WINRT variabled are added when WinRT generators are used.

Besides, the hack of changing platform name is no longer required because a tag <WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport> can enable the utility target type on ARM.

This patch is separated into 3 files. They can be applied one by one to complete the WinRT support in CMake.
(0035054)
Brad King   
2014-02-07 10:44   
Re 0013511:0035038: Nice work! Here are a few comments:

I'd prefer not to add another space-separated field to the generator name. Rather than " WinRT", " Win64 WinRT", and " ARM WinRT", how about " WinRT-$arch", e.g. "WinRT-ARM"? (BTW, does WinRT actually support all these architectures?)

Please drop the project() command change that magically picks CXX-only or C+CXX based on flags or the generator names. The command should remain simple. WinRT-only projects should list their languages explicitly. Projects that can build wither as WinRT or others can use the NONE option to project() and then explicitly enable_language() whatever they want based on flags or the generator name.

Please fix the coding style to keep C++ sources under 79 columns.

Thanks!
(0035059)
Minmin Gong   
2014-02-08 22:19   
Thanks for you comments. I've updated my patches to V4.

The generator names are changed to " WinRT-x86"/" WinRT-ARM"/" WinRT-x64" suffix. Yes, currently WinRT supports all those)

Also, the modification to project() is dropped. And the code are limited to < 80 columns.
(0035093)
Brad King   
2014-02-11 10:44   
Re 0013511:0035059: Thanks. These look good so far. (Please provide further patches as follow-ons to the v4 series. I will squash the corrections in to the earlier patches while applying.)

The logic added to Modules/CMakeDetermineSystem.cmake no longer looks correct with the new generator names. Shouldn't it use MSVC_C_ARCHITECTURE_ID just like the WinCE support does?

Currently the version of WinRT is hard-coded to 8.0. In the future more versions will be available. At that point we will need a way to distinguish them and choose one. How do you propose we do that?
(0035105)
Minmin Gong   
2014-02-14 02:14   
> The logic added to Modules/CMakeDetermineSystem.cmake no longer looks correct with the new generator names. Shouldn't it use MSVC_C_ARCHITECTURE_ID just like the WinCE support does?

I've tried MSVC_C_ARCHITECTURE_ID before. But the CompilerIdC.exe generated with WinRT configuration is not able to run under Windows. All WinRT apps should be packaged into a WinStore app and digital signed. So MSVC_C_ARCHITECTURE_ID is empty. I'll explore the <WindowsSDKDesktopARMSupport> tag. It may work here to generate a runable exe on host system.

> Currently the version of WinRT is hard-coded to 8.0. In the future more versions will be available. At that point we will need a way to distinguish them and choose one. How do you propose we do that?

In VS12's generator, the WinRTVersion is "8.1". In VS12, There is a tag <ApplicationTypeRevision> in vcxproj that contains the version of WinRT. I think it will be a key in register to indicate the available version installed, just like the WinCE does. But I don't know the exact way to detect it.
(0035111)
Brad King   
2014-02-14 13:54   
Re 0013511:0035105: With generator "Visual Studio 12 2013 WinRT-x64" I get:

 $ grep App CompilerIdC/CompilerIdC.vcxproj
    <ApplicationType>Windows Store</ApplicationType>
    <ConfigurationType>Application</ConfigurationType>
    <WindowsAppContainer>true</WindowsAppContainer>
 $ grep MSVC_C_ARCH CMakeCCompiler.cmake
 set(MSVC_C_ARCHITECTURE_ID x64)

so it looks like your compiler id changes make the architecture get detected correctly. This is on a Win7 host with VS 2013 for Windows Desktop. (Even if it were not detected correctly then your CMakeDtermineSystem changes still need to be updated for the new generator name. Or perhaps in addition to CMAKE_VS_WINRT_VERSION the generator should set CMAKE_VS_WINRT_ARCHITECTURE.)

Please investigate further into the version issue. We need to be able to gracefully handle new WinRT versions in the future.
(0035113)
Minmin Gong   
2014-02-15 02:06   
Yes, in CMakeCCompiler.cmake, MSVC_C_ARCHITECTURE_ID is correct (besides the problem caused by wrong generator name). But in CMakeSystem.cmake, CMAKE_SYSTEM_PROCESSOR is empty. I think it's because by the time CMakeSystem.cmake is generated, C compiler has not been determined yet. So MSVC_C_ARCHITECTURE_ID is not assigned. How can I handle this? Hardcode a CMAKE_VS_WINRT_ARCHITECTURE definitely can solve this. But WinCE doesn't do that right?
 
For the version issue, sure I'll figure it out soon.
(0035122)
Brad King   
2014-02-17 08:49   
Re 0013511:0035113: Actually now that you point it out I'm not sure WinCE is handling that correctly. If the generator knows the architecture then I think communicating it to CMakeSystem.cmake via something like CMAKE_VS_WINRT_ARCHITECTURE can work.

This is really touching on cross-compiling. CMake normally handles that with a CMAKE_TOOLCHAIN_FILE that specifies the target architecture up front. However, that was originally done with Makefile generators. We have not really investigated cross-compiling in combination with builtin VS support before.
(0035134)
Brad King   
2014-02-17 11:38   
I think the changes under discussion here are beyond the scope of a simple bug-fix patch typically posted in issue tracker entries. The design discussion and review here would be better held with a broader audience on the cmake-developers mailing list. Others are interested in additional platform support too, such as in this thread:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9416/focus=9424 [^]

Minmin Gong, please join the list at

 http://www.cmake.org/mailman/listinfo/cmake-developers [^]

and post your work there. See also the CONTRIBUTING.rst instructions:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=CONTRIBUTING.rst;hb=b1d34182 [^]

Thanks.
(0035137)
Minmin Gong   
2014-02-18 00:10   
Thanks, I've just subscribed the cmake developers mail list.
(0035441)
Minmin Gong   
2014-03-19 21:29   
Sorry for the delay. Patch V5 is finished. According to http://msdn.microsoft.com/en-us/library/windows/apps/dn263114.aspx#AddMaintenanceTools, [^] the version of WinRT is based on toolset. v110 is WinRT 8.0, v120 is WinRT 8.1. This is added in my new patches.

Also, I've send a email to cmake-developers for more discussion.
(0035464)
Brad King   
2014-03-21 10:34   
Re 0013511:0035441: I did not see an email on cmake-developers related to this. I see an older posting to the user mailing list:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48384 [^]

The two lists are at:

 http://www.cmake.org/mailman/listinfo/cmake [^]
 http://www.cmake.org/mailman/listinfo/cmake-developers [^]

The latter is the developer list.
(0035505)
Minmin Gong   
2014-03-25 06:06   
Re 0013511:0035464:

OK, it looks like my subscription goes wrong. I never received the confirmation mail. I'll re do it again.

Thanks.
(0036787)
Brad King   
2014-09-12 09:42   
The development version of CMake now supports running with

 cmake .. -G "Visual Studio 11 2012" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.0
 cmake .. -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.1
 cmake .. -G "Visual Studio 11 2012" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=8.0
 cmake .. -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=8.1

to generate project files for Windows Phone and Store.

There is also a VS_WINRT_COMPONENT target property that can make a shared library into a WinRT component library.

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 [^]
(0038118)
Robert Maynard   
2015-03-02 08:57   
Closing resolved issues that have not been updated in more than 4 months.