[CMake] Fwd: [PATCH] Add support for Metro apps

Tue Apr 1 04:12:46 EDT 2014

Hi Gilles,

I have done some work to extend CMAKE so that it generates projects that support the different platforms of Windows Phone (x86/ARM) inside a single SLN  in exactly this way, and I sent a patch to the dev-list last year. It is currently being used on a large scale cross-platform project I am working on.

To David's point it is another full generator ("Visual Studio 2012 Windows Phone 8") and doesn't rely on toolchain - so at least it is clear what it is doing. 

It's been on the back-burner for a bit on my side, as initial support only worked for static libraries and I got busy with other things. Since I last reported I have managed to extend this to Windows Runtime Component DLLs but I have yet to sanitise this for review. This is mainly around getting VS to take care of linking automatically, as CMAKE can't track all the combinations of binaries in all platform architectures.

I haven't supported Windows Phone C++/DirectX EXE projects.

Minmin: I think the general principles above are extendable to Windows Store Apps: i.e. support for X64 should be trivial. Also be aware that there EXE project types that are not available to Windows Phone that Windows Store supports (e.g. C++/XAML). 

The code is at: https://github.com/paulannetts/CMake
Branches: vs11-multi-platform, windows-phone-8, wp8-runtime-component

Hopefully we can pool resources and come up with a good combined solution!

Paul Annetts.

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Gilles Khouzam
Sent: 31 March 2014 19:25
To: David Cole; minmin.gong at gmail.com; cmake-developers at cmake.org; cmake at cmake.org
Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps

Hi,

I'm new to CMake but am looking to help with this effort. 

I'm wondering if it would make more sense (and if it's possible) to have the WinRT flavors as separate platforms within the same solution as you would get if you create a new WinRT project in Visual Studio, instead of having 3 different configurations. 

I'm looking at also adding WinRT support for Windows Phone and I think that trying to minimize the generators might make more sense.

~Gilles

-----Original Message-----
From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Cole
Sent: Monday, March 31, 2014 07:13
To: minmin.gong at gmail.com; cmake-developers at cmake.org; cmake at cmake.org
Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps

Thanks for working on this. It will be cool to be able to build Metro apps using CMake.

One thing I think is crucial here is to include somewhere an example or test project that actually builds a Metro app, and shows how you have to construct the CMakeLists for it, and any special considerations needed when running CMake to generate the project. Without that, I have no clue where to start on evaluating whether these patches are sufficient or not.

Ideally, the example/test will be:
- here, use something like this CMakeLists.txt (and then show one)
- run CMake with the XXX generator
- build as usual

Could you add a test/example somewhere that shows how to use this?

And now, the following is no criticism of your patch, or your attempts to get this functionality into CMake, .... *but*:

- there are too many ways to "cross compile" for CMake already, and it would be nice if this way was like one of the other ways rather than something entirely different.

Right now, CMake already "supports":
- "true" cross-compiling using a makefile based generator and a toolchain file
- building universal binaries on OSX, but not with a toolchain file
- building iOS apps on OSX, but with special variables and properties that need setting
- building 32-bit and 64-bit windows apps from the same source tree, but with VS generators, using 2 different build trees each with a different generator, or with non-VS generators, using 2 different build trees, and different environments to define the tools

And now there's this. Which I guess is closest to the VS different generator approach.

It would be super awesome if somebody could come up with a coherent way to unify all this. (Steve and Eric: hopefully you are considering making the Android stuff you're about to work on blend in closely with one of these existing models rather than introducing yet another cross-compiling model....)

My 2 cents -- again: thanks for your contribution and keep up the good work. Overall, CMake is still squarely the best way to build cross-platform C++ based projects. And supporting as many platforms as feasible is one of the contributing factors that makes it so.

David C.

-----Original Message-----
From: Minmin Gong <minmin.gong at gmail.com>
To: cmake-developers <cmake-developers at cmake.org>; cmake <cmake at cmake.org>
Sent: Mon, Mar 31, 2014 2:35 am
Subject: [CMake] Fwd:  [PATCH] Add support for Metro apps

Hi cmake developers and users,
This is a extend discussion of this ticket: 
http://www.cmake.org/Bug/view.php?id=13511.

In our project, we need to build an Win8+ Metro app. Currently the CMake do support VS_WINRT_EXTENSIONS. However, if you want to build an exe instead of dll or lib, even with x86 or x64, it always fails because lacking of some tags in vcxproj and sln.

So I made this patch for WinRT/Metro apps, based on the master branch of CMake. In this patch, 

1. WinRT-ARM, WinRT-x86, WinRT-x64 generators are added for generating WinRT special projects. CMAKE_VS_WINRT_VERSION is defined inside.

2. Add AppContainerApplication, ApplicationType, 
MinimumVisualStudioVersion and ApplicationTypeRevision tags to vcxproj 
in WinRT project.
3. Recognize AppxManifest file type.
4. A dedicated boolean source file property "VS_WINRT_CONTENT" is 
added. Generator expressions is also supported here.
5. Add "Deploy.0" in .sln for deploy WinRT apps by default, as WinCE 
apps do.
6. Add PackageCertificateKeyFile tag to vcxproj for package 
certification.

Thanks for advices from Martell Malone, Daniel Pfeifer, Brad King, 
Patrick R. Gansterer, and other developers and users of CMake. More 
comments are welcomed.

--
Minmin Gong

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For 
more
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake