MantisBT - CMake |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0013511 | CMake | CMake | public | 2012-09-03 10:15 | 2015-03-02 08:57 |
|
Reporter | Sergey Yakovlev | |
Assigned To | Brad King | |
Priority | high | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | |
Platform | | OS | Windows 8 RTM x64 | OS Version | |
Product Version | CMake 2.8.9 | |
Target Version | CMake 3.1 | Fixed in Version | CMake 3.1 | |
|
Summary | 0013511: Add support for WinRT platforms and "metro" apps |
Description | Environment:
* 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 Information | VS2012 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).
|
Tags | No tags attached. |
Relationships | related to | 0013077 | closed | Brad King | Generator for Visual Studio 11 ARM | related to | 0012930 | closed | Brad King | [patch] CMake does not support Visual Studio 11 WinRT project type | has duplicate | 0013749 | closed | | Cannot target Windows 8 RT from CMake without workarounds. | has duplicate | 0013498 | closed | | CMake does not fully support Visual Studio 11 WinRT project type | related to | 0013791 | closed | Brad King | CMake does not support generating projects for Windows Phone 8. | related to | 0014129 | closed | Brad King | CMakeDetermineCompilerId.cmake is broken for VS 2011/2012 ARM targets | related to | 0014596 | closed | | No PackageCertificateKeyFile tag |
|
Attached Files | AppContainerApplication.patch (737) 2012-12-14 00:56 https://public.kitware.com/Bug/file/4592/AppContainerApplication.patch
AppxManifest.patch (577) 2012-12-14 01:58 https://public.kitware.com/Bug/file/4593/AppxManifest.patch
TryCompile.patch (735) 2012-12-17 23:58 https://public.kitware.com/Bug/file/4597/TryCompile.patch
VS11ArmPatches.patch (10,485) 2013-04-15 09:35 https://public.kitware.com/Bug/file/4736/VS11ArmPatches.patch
WinRTon2.8.12.patch (3,499) 2013-11-09 10:02 https://public.kitware.com/Bug/file/4943/WinRTon2.8.12.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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 | bug_revision_view_page.php?bugnote_id=32952#r1145 |
2013-04-28 18:28 | Martell Malone | Note Edited: 0032952 | bug_revision_view_page.php?bugnote_id=32952#r1146 |
2013-04-28 18:32 | Martell Malone | Note Edited: 0032952 | bug_revision_view_page.php?bugnote_id=32952#r1147 |
2013-04-28 18:41 | Martell Malone | Note Edited: 0032952 | bug_revision_view_page.php?bugnote_id=32952#r1148 |
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 | bug_revision_view_page.php?bugnote_id=33275#r1185 |
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 | bug_revision_view_page.php?bugnote_id=34525#r1320 |
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 | bug_revision_view_page.php?bugnote_id=36787#r1569 |
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 |
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
|
|
|
|
(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
|
|
|
|
(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
|
|
|
|
(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
|
|
|
|
(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
|
|
|
|
(0035464)
|
Brad King
|
2014-03-21 10:34
|
|
|
|
(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. |
|