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"? Its 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 its 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.k...@kitware.com] Sent: 17 October 2013 14:13 To: Patrick Gansterer Cc: Paul Annetts; cmake-developers@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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers