View Issue Details Jump to Notes ] Print ]
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!
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.
Attached Filespatch file icon AppContainerApplication.patch [^] (737 bytes) 2012-12-14 00:56 [Show Content]
patch file icon AppxManifest.patch [^] (577 bytes) 2012-12-14 01:58 [Show Content]
patch file icon TryCompile.patch [^] (735 bytes) 2012-12-17 23:58 [Show Content]
patch file icon VS11ArmPatches.patch [^] (10,485 bytes) 2013-04-15 09:35 [Show Content]
patch file icon WinRTon2.8.12.patch [^] (3,499 bytes) 2013-11-09 10:02 [Show Content]
patch file icon WinRTon2.8.12.v2.patch [^] (3,953 bytes) 2013-11-11 20:38 [Show Content]
patch file icon WinRTon2.8.12.1.v3.patch [^] (6,685 bytes) 2013-11-23 10:45 [Show Content]
patch file icon WinRTon2.8.12.1.v4.patch [^] (9,056 bytes) 2013-11-25 10:15 [Show Content]
patch file icon WinRTon2.8.12.1.v5.patch [^] (11,116 bytes) 2013-11-26 10:19 [Show Content]
patch file icon 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.patch [^] (24,228 bytes) 2014-01-31 01:49 [Show Content]
patch file icon 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v2.patch [^] (24,293 bytes) 2014-01-31 23:10 [Show Content]
patch file icon 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch [^] (11,552 bytes) 2014-02-05 01:43 [Show Content]
patch file icon 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch [^] (7,190 bytes) 2014-02-05 01:43 [Show Content]
patch file icon 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch [^] (3,521 bytes) 2014-02-05 01:44 [Show Content]
patch file icon 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch [^] (10,491 bytes) 2014-02-08 22:15 [Show Content]
patch file icon 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch [^] (7,039 bytes) 2014-02-08 22:15 [Show Content]
patch file icon 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch [^] (2,413 bytes) 2014-02-08 22:16 [Show Content]
patch file icon 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch [^] (10,975 bytes) 2014-03-19 21:30 [Show Content]
patch file icon 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch [^] (6,907 bytes) 2014-03-19 21:30 [Show Content]
patch file icon 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch [^] (2,414 bytes) 2014-03-19 21:30 [Show Content]

 Relationships
related to 0013077closedBrad King Generator for Visual Studio 11 ARM 
related to 0012930closedBrad 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 0013791closedBrad King CMake does not support generating projects for Windows Phone 8. 
related to 0014129closedBrad King CMakeDetermineCompilerId.cmake is broken for VS 2011/2012 ARM targets 
related to 0014596closed No PackageCertificateKeyFile tag 

  Notes
(0030821)
Brad King (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (reporter)
2012-12-14 01:59

Another AppxManifest.patch fix the WinRT's new file type appxmanifest.
(0031890)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
2012-12-18 07:58

Changing to feature request because this is really about adding support for a new platform.
(0032787)
squirrelfm (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
2013-11-11 20:38

Updated my patch. Add VS2013 with Win 8.1 app type support.
(0034438)
Brad King (manager)
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 (manager)
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 (reporter)
2013-11-23 10:51
edited on: 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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
2014-02-18 00:10

Thanks, I've just subscribed the cmake developers mail list.
(0035441)
Minmin Gong (reporter)
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 (manager)
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 (reporter)
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 (manager)
2014-09-12 09:42
edited on: 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 (manager)
2015-03-02 08:57

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-09-03 10:15 Sergey Yakovlev New Issue
2012-09-03 10:21 Brad King Relationship added related to 0012930
2012-09-03 10:22 Brad King Relationship added related to 0013077
2012-09-03 10:22 Brad King Relationship deleted related to 0012930
2012-09-03 10:25 Brad King Relationship added related to 0012930
2012-09-03 10:27 Brad King Note Added: 0030821
2012-09-03 10:27 Brad King Status new => backlog
2012-09-03 10:27 Brad King Target Version => CMake 2.8.10
2012-10-18 11:18 David Cole Note Added: 0031271
2012-10-18 11:18 David Cole Target Version CMake 2.8.10 => CMake 2.8.11
2012-11-13 22:45 Yan Cheng CHEOK Note Added: 0031547
2012-11-14 07:20 Brad King Note Added: 0031551
2012-11-28 08:33 Brad King Relationship added related to 0013749
2012-11-28 08:36 Brad King Relationship added related to 0013498
2012-11-28 08:42 Brad King Note Added: 0031737
2012-12-14 00:56 Minmin Gong File Added: AppContainerApplication.patch
2012-12-14 00:58 Minmin Gong Note Added: 0031882
2012-12-14 01:58 Minmin Gong File Added: AppxManifest.patch
2012-12-14 01:59 Minmin Gong Note Added: 0031884
2012-12-14 08:28 Brad King Note Added: 0031890
2012-12-17 00:08 Minmin Gong Note Added: 0031904
2012-12-17 09:40 Brad King Note Added: 0031907
2012-12-17 23:58 Minmin Gong File Added: TryCompile.patch
2012-12-18 00:02 Minmin Gong Note Added: 0031910
2012-12-18 07:30 Intrepid Soldier Note Added: 0031912
2012-12-18 07:51 Brad King Note Deleted: 0031912
2012-12-18 07:55 Brad King Note Added: 0031913
2012-12-18 07:58 Brad King Note Added: 0031914
2012-12-18 07:58 Brad King Severity major => feature
2012-12-18 07:58 Brad King Summary Cannot use with VS 2012 RTM for ARM platform => Add support for WinRT platforms and "metro" apps
2012-12-18 07:58 Brad King Target Version CMake 2.8.11 =>
2012-12-18 07:59 Brad King Relationship replaced has duplicate 0013498
2012-12-18 08:01 Brad King Relationship replaced has duplicate 0013749
2012-12-18 08:02 Brad King Relationship added has duplicate 0013791
2012-12-18 09:43 Brad King Relationship replaced related to 0013791
2013-04-09 11:00 squirrelfm File Added: CMakeTestCXXCompiler.cmake.patch
2013-04-09 11:01 squirrelfm File Added: cmCoreTryCompile.cxx.patch
2013-04-09 11:03 squirrelfm File Added: cmCoreTryCompile.h.patch
2013-04-09 11:03 squirrelfm File Added: cmProjectCommand.cxx.patch
2013-04-09 11:03 squirrelfm File Added: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-09 11:39 squirrelfm Note Added: 0032787
2013-04-09 13:14 Brad King File Deleted: CMakeTestCXXCompiler.cmake.patch
2013-04-09 13:14 Brad King File Deleted: cmCoreTryCompile.cxx.patch
2013-04-09 13:14 Brad King File Deleted: cmCoreTryCompile.h.patch
2013-04-09 13:15 Brad King File Deleted: cmProjectCommand.cxx.patch
2013-04-09 13:15 Brad King File Deleted: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-10 12:08 squirrelfm File Added: CMakeTestCXXCompiler.cmake.patch
2013-04-10 12:08 squirrelfm File Added: cmCoreTryCompile.cxx.patch
2013-04-10 12:08 squirrelfm File Added: cmCoreTryCompile.h.patch
2013-04-10 12:10 squirrelfm File Added: cmLocalGenerator.cxx.patch
2013-04-10 12:10 squirrelfm File Added: cmLocalGenerator.h.patch
2013-04-10 12:10 squirrelfm File Added: cmProjectCommand.cxx.patch
2013-04-10 12:15 squirrelfm File Added: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-12 08:39 Brad King File Deleted: CMakeTestCXXCompiler.cmake.patch
2013-04-12 08:39 Brad King File Deleted: cmCoreTryCompile.cxx.patch
2013-04-12 08:39 Brad King File Deleted: cmCoreTryCompile.h.patch
2013-04-12 08:39 Brad King File Deleted: cmLocalGenerator.cxx.patch
2013-04-12 08:39 Brad King File Deleted: cmLocalGenerator.h.patch
2013-04-12 08:39 Brad King File Deleted: cmProjectCommand.cxx.patch
2013-04-12 08:39 Brad King File Deleted: cmVisualStudio10TargetGenerator.cxx.patch
2013-04-12 08:40 Brad King Note Added: 0032813
2013-04-15 09:35 squirrelfm Note Added: 0032833
2013-04-15 09:35 squirrelfm File Added: VS11ArmPatches.patch
2013-04-15 09:35 squirrelfm Note Deleted: 0032833
2013-04-15 09:41 squirrelfm Note Added: 0032834
2013-04-15 10:10 Brad King Note Added: 0032836
2013-04-28 18:18 Martell Malone Note Added: 0032952
2013-04-28 18:25 Martell Malone Note Edited: 0032952
2013-04-28 18:28 Martell Malone Note Edited: 0032952
2013-04-28 18:32 Martell Malone Note Edited: 0032952
2013-04-28 18:41 Martell Malone Note Edited: 0032952
2013-05-07 09:35 Brad King Relationship added related to 0014129
2013-06-12 02:03 ixSci Note Added: 0033275
2013-06-12 02:05 ixSci Note Edited: 0033275
2013-09-03 09:16 Daniel Pfeifer Note Added: 0033777
2013-11-09 10:02 Minmin Gong File Added: WinRTon2.8.12.patch
2013-11-09 10:11 Minmin Gong Note Added: 0034429
2013-11-11 20:38 Minmin Gong File Added: WinRTon2.8.12.v2.patch
2013-11-11 20:38 Minmin Gong Note Added: 0034431
2013-11-12 14:04 Brad King Note Added: 0034438
2013-11-12 14:05 Brad King Note Added: 0034439
2013-11-23 10:45 Minmin Gong File Added: WinRTon2.8.12.1.v3.patch
2013-11-23 10:51 Minmin Gong Note Added: 0034525
2013-11-23 10:51 Minmin Gong Note Edited: 0034525
2013-11-25 10:15 Minmin Gong File Added: WinRTon2.8.12.1.v4.patch
2013-11-25 10:22 Minmin Gong Note Added: 0034551
2013-11-26 09:24 Brad King Relationship added related to 0014596
2013-11-26 10:19 Minmin Gong File Added: WinRTon2.8.12.1.v5.patch
2013-11-26 10:22 Minmin Gong Note Added: 0034568
2013-11-26 10:33 Brad King Note Added: 0034569
2014-01-31 01:49 Minmin Gong File Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.patch
2014-01-31 01:57 Minmin Gong Note Added: 0035014
2014-01-31 07:51 Patrick R. Gansterer Note Added: 0035015
2014-01-31 23:10 Minmin Gong File Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v2.patch
2014-01-31 23:18 Minmin Gong Note Added: 0035016
2014-02-01 05:41 Patrick R. Gansterer Note Added: 0035017
2014-02-01 23:38 Minmin Gong Note Added: 0035019
2014-02-05 01:43 Minmin Gong File Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
2014-02-05 01:43 Minmin Gong File Added: 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
2014-02-05 01:44 Minmin Gong File Added: 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v3.patch
2014-02-05 02:09 Minmin Gong Note Added: 0035038
2014-02-07 10:44 Brad King Note Added: 0035054
2014-02-08 22:15 Minmin Gong File Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
2014-02-08 22:15 Minmin Gong File Added: 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
2014-02-08 22:16 Minmin Gong File Added: 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v4.patch
2014-02-08 22:19 Minmin Gong Note Added: 0035059
2014-02-11 10:44 Brad King Note Added: 0035093
2014-02-14 02:14 Minmin Gong Note Added: 0035105
2014-02-14 13:54 Brad King Note Added: 0035111
2014-02-15 02:06 Minmin Gong Note Added: 0035113
2014-02-17 08:49 Brad King Note Added: 0035122
2014-02-17 11:38 Brad King Note Added: 0035134
2014-02-18 00:10 Minmin Gong Note Added: 0035137
2014-03-19 21:29 Minmin Gong Note Added: 0035441
2014-03-19 21:30 Minmin Gong File Added: 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
2014-03-19 21:30 Minmin Gong File Added: 0002-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
2014-03-19 21:30 Minmin Gong File Added: 0003-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v5.patch
2014-03-21 10:34 Brad King Note Added: 0035464
2014-03-25 06:06 Minmin Gong Note Added: 0035505
2014-09-12 09:42 Brad King Note Added: 0036787
2014-09-12 09:42 Brad King Note Edited: 0036787
2014-09-12 09:43 Brad King Assigned To => Brad King
2014-09-12 09:43 Brad King Status backlog => resolved
2014-09-12 09:43 Brad King Resolution open => fixed
2014-09-12 09:43 Brad King Fixed in Version => CMake 3.1
2014-09-12 09:43 Brad King Target Version => CMake 3.1
2015-03-02 08:57 Robert Maynard Note Added: 0038118
2015-03-02 08:57 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team