[cmake-developers] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator

[Paul Annetts]

Thanks for such quick responses in reviewing my patch!

One thing to bear in mind with this patch is that I'm coming at this as a
Windows Phone developer trying to use CMAKE rather than a CMAKE developer
trying to support Windows Phone
 So I'm trying to make CMAKE fit the best
developer flow I can which I think is a sensible starting point. And for me
it was obvious that I should attempt to make CMAKE support multi-platform
(for reasons I outline below).  Extending VS11 to multiple CPU architectures
wasn't a conscious thing I set out to do, but Brad noticed that I had
attempted it, and I happily reworked my patch to see where it would lead.

Based on the feedback I'm wondering whether the multi-platform should be
limited just to Windows Phone 8 (and a future Windows Store generator?)
until the find_package() issues are addressed. There are tangible
productivity benefits to multi-platform for WP8, which I suspect also apply
to Windows Store apps too. Brad: that would answer your query about VS10
support, although to answer your question: yes this could be applied to VS10
if wanted.

It's worth bearing in mind that for Windows, x86 support will still allow
you to hit the vast majority of installed PCs and most program use-cases,
even though x64 OS are obviously now much more common than before. The only
misses are for huge programs which require 64-bit memory support and for
"PCs" with ARM processors. Bear in mind that ARM support is only an issue
for Windows 8/8.1 RT (e.g. Surface RT and Surface 2), and that on these ARM
devices you can only compile against the Windows Store APIs anyhow, not
against the full Win32 API.

Paul.

Dealing with your points:
PATRICK:
> if(CMAKE_SIZEOF_VOID_P EQUAL 8)
 >   message(FATAL_ERROR "Building x64")
> endif()

Could easily be replaced with some form of compiler capability detection
then at compile time using static_assert. That would have the advantage of
using standard language features where they are available.
	static_assert(sizeof(void *) == 4, "64-bit code generation is not
supported.");
	From <http://msdn.microsoft.com/en-us/library/vstudio/dd293588.aspx>


Once you know from a CMAKE perspective that you are in a known API set such
as Windows Phone, it is quite straightforward to use language features or
compiler macros rather than CMAKE macros to detect the CPU architecture, the
difference in endianness etc.

PATRICK:
> That might not be a big problem for most projects, but from my experience
95% of the CMake project link against a 3rd party library with
find_package() which are different on x86/x64/ARM/... platform.
> I'm against adding this feature until this problem is solved, since it
adds no real benefit compared to the confusion for users with their
expectations. :-(
BRAD:
> Ugh, you're right.  That completely slipped my mind.  We can support
multiple CMAKE_OSX_ARCHITECTURES on OS X 
> because they have frameworks built as universal binaries so linking to one
library file can support multiple 
> architectures.  That is not the case on Windows, making this feature
unrealistic without teaching find modules to 
> provide imported targets with per-architecture locations.  That is a much
bigger task :(

Ouch - indeed I hadn't considered that
 Of course it is currently impossible
for Windows Phone / (Windows Store?) to have any packages that
find_package() might find anyhow (although in the longer term that would be
nice to have).

PATRICK:
> @windows-phone-8: Why does it depend on the multi platform stuff? Is it
possible that it's only 
> needed to bypass the correct platform detection? Otherwise it shouldn't be
a problem to add 
> the "Windows-Phone-8" generator like the Windows CE ones. Since the
platform name for 
> Windows-Phone 8 seams to be the same like for the desktop versions
(compared to WinCE 
> where they need to match a specific installed SDK name) it might be enough
for the user to set 
> CMAKE_GENERATOR_TOOLSET to "v110_wp80"?

It’s not enough to set v110_wp80 as the default linker settings in
particular are quite different (e.g. there is no kernel.lib in Windows
Phone).
 
However primarily it’s the desire to easily switch between x86 and ARM (as
simple as just changing "Device" to "Emulator" in the VS IDE). My use-case
for C++ on WP8 is for it to interface with C# where C# provides the GUI, C++
the guts of the app. CMAKE doesn't support C# in any form, let alone Windows
Phone apps. 

In this case and the current CMAKE patch you can:
	1) Generate a single CMAKE output directory supporting x86 and ARM. 
	2) Import the C++ projects it into a new Visual Studio solution
which contains the code for the C# GUI.
Not perfect, but relatively easy to do once you fix the project GUIDs that
CMAKE generates so that they don't keep changing as VS doesn't like that at
all. I suspect this is no worse than what you would need to do to support
Java GUI on top of C++/NDK on Android, but I'm no expert on that.

Compare with the alternative, non-multi-platform CMAKE solution. In my case
this would involve:
	1) Generate a CMAKE ARM build output directory for device builds.
	2) Generate a CMAKE x86 build output directory for emulator builds.
	3) Generate an ARM Visual Studio .sln file with a copy of my C# GUI
code, linked to the ARM CMAKE directory.
	4) Generate an x86 Visual Studio .sln file with a 2nd "copy" of my
C# GUI code, linked to the x86 CMAKE directory. 
	5) As these are duplicate C# projects I'd have to find some hack to
keep the "make" (.csproj) files in sync for each platform, such as "Project
Linker". 
That is *not* going to be fun to maintain


This is also a use-case for Windows Store C#/XAML and HTML5/JS apps,
although Windows Store gains a C++/XAML GUI option in addition to the
DirectX option on the phone.
  

BRAD:
> Why do you need the dedicated multi-platform target generator?
> Can't the normal cmVisualStudio10TargetGenerator be taught to support
multiple platforms and just "loop" over a 
> single platform when needed?
I wanted to keep the existing generator as close to the same as possible to
reduce code-churn and regression risk, but extend it where needed to
multi-platform.

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: 17 October 2013 14:13
To: Patrick Gansterer
Cc: Paul Annetts; cmake-developers at cmake.org
Subject: Re: [cmake-developers] Patches for Visual Studio multi-CPU
architecture project generation and a Windows-Phone-8 generator

On 10/17/2013 03:42 AM, Patrick Gansterer wrote:
> ...project link against a 3rd party library with find_package() which 
> are different on x86/x64/ARM/... platform.
> I'm against adding this feature until this problem is solved

Ugh, you're right.  That completely slipped my mind.  We can support
multiple CMAKE_OSX_ARCHITECTURES on OS X because they have frameworks built
as universal binaries so linking to one library file can support multiple
architectures.  That is not the case on Windows, making this feature
unrealistic without teaching find modules to provide imported targets with
per-architecture locations.  That is a much bigger task :(

-Brad