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

Paul Annetts paul at lightunobscured.com
Fri Oct 18 12:03:12 EDT 2013


Hi Patrick,


Any multi-CPU arch generator which tries to at one point during the CMAKE configure step to determine endianess or sizeof(T*) is always going to get the answer wrong for one or more of those architectures. It is not difficult to find out these values from the compiler or standard C/C++. However such a generator will share a common API across the CPU archs and so have the potential to add significant user benefit.


My experience is that WP8 benefits greatly from multi-platform support, so that practical usage of CMAKE is kept simple and flexible for end users. In my opinion this outweighs the theoretical benefit of find_package() for WP8 (for a sum total of 0 current compatible binaries).


​However on balance I don’t think adding multi-platform to the general VS toolchain adds any value. For example there’s no point in compiling CMAKE for x64 as it doesn't need to address > 4GB RAM and it won't even be possible to compile it for ARM as CMAKE can’t run under Windows 8 RT.


Paul.



From: 'Patrick Gansterer'
Sent: ‎Friday‎, ‎18‎ ‎October‎ ‎2013 ‎15‎:‎48
To: Paul Annetts
Cc: 'Brad King', cmake-developers at cmake.org





On 18.10.2013, at 15:39, Paul Annetts wrote:
> 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.

I know. ;-) I only wanted to show you a simple CMake code which does not work with your multi-platform patch. It might work for some projects (without such checks, find_package(), ...), but not in general.

> 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).

The important part of my statement was "for the" user: If the user sets the toolset to a Windwos Phone one CMake can detect that and do not link against kernel.lib (and all other standard libs).

-- Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20131018/53bff203/attachment.html>


More information about the cmake-developers mailing list