<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">> No "CMake time" decisions are possible based on the configuration</span><br><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I have a project that uses some unix libraries. I use find_package() to locate them. On Windows platform find_package() obviously fails so I maintain folder with prebuilt binaries. So my CMakeLists.txt looks like:</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><div style><font face="arial, sans-serif">if (${CMAKE_SYSTEM_NAME} MATCHES "Windows")</font></div><div style><font face="arial, sans-serif">    set(CMAKE_LIBRARY_PATH "win32/x86/lib")</font></div><div style><font face="arial, sans-serif">endif()</font></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">find_package(A REQUIRED)</font></div><div style><font face="arial, sans-serif">find_package(B REQUIRED)</font></div><div style><font face="arial, sans-serif">find_package(C REQUIRED)</font></div></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Now I want to add x64 build support. Obviously now it fails when tries to link x64 binary to x86 prebuilt libs. I cant use </font><span style="font-family:arial,sans-serif;font-size:13px">CMAKE_SYSTEM_PROCESSOR  because its always defined to AMD64. </span><font face="arial, sans-serif">Also I cant use VS $(Platform) variable because find_package() runs at "cmake time". So how I should handle it without "cmake time" decisions? Use internal undocumented </font><span style="font-size:13px;font-family:arial,sans-serif">MSVC_C_ARCHITECTURE_ID? Use CMAKE_CL_64\CMAKE_FORCE_WIN64\CMAKE_FORCE_IA64 vars that are x64-only hack that will fail for ARM build? Use </span><span style="font-size:13px;font-family:arial,sans-serif">CMAKE_GENERATOR var and find "Win64"\"ARM" substrings in it?</span></div><div style><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div style><span style="font-size:13px;font-family:arial,sans-serif">I'm really running out of ideas and will appreciate any help in this question.</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>Regards, Alexey</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 2:35 AM, Gilles Khouzam <span dir="ltr"><<a href="mailto:Gilles.Khouzam@microsoft.com" target="_blank">Gilles.Khouzam@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David, Alexey<br>
<br>
I'm glad to hear your enthusiasm about our involvement with CMake. We're still trying to understand the issues that people are facing and how we can help improve those. The multi-platform support is something somewhat experimental that will have issues, but getting feedback will help address the issues that you might run into.<br>
<br>
Alexey, the issue with CMAKE_SYSTEM_PROCESSOR seems to come from the CMakeDetermineSystem.cmake (lines 110 and below) file which only sets it for WINCE based on the MSVC_C_ARCHITECTURE_ID and uses the HOST processor otherwise. That's probably why you're seeing AMD64 all the time. My initial thought is that using MSVC_C_ARCHITECTURE_ID should give you at least the right processor for the compile.<br>
<br>
BTW, I've only enabled the multiplatform support for cross-compiling for Windows Phone and Windows Store apps (to reduce the potential regressions) but if you would like to have it for native Windows apps, I should be able to easily enable it.<br>
<br>
Looking forward to being able to help more.<br>
<span class="HOEnZb"><font color="#888888"><br>
Gilles Khouzam<br>
Senior Development Lead<br>
Microsoft OSG<br>
</font></span><span class="im HOEnZb"><br>
-----Original Message-----<br>
From: David Cole [mailto:<a href="mailto:dlrdave@aol.com">dlrdave@aol.com</a>]<br>
Sent: Tuesday, September 16, 2014 03:37<br>
To: <a href="mailto:alexey.petruchik@gmail.com">alexey.petruchik@gmail.com</a>; Gilles Khouzam<br>
Cc: <a href="mailto:cmake@cmake.org">cmake@cmake.org</a><br>
Subject: Re: [CMake] Get Visual Studio target Arch<br>
<br>
</span><div class="HOEnZb"><div class="h5">> I still cant really make some arch specific ifdefs in my cmake scripts<br>
> using this approach.<br>
<br>
<br>
That's the point of a multi-configuration, multi-architecture Visual Studio solution: you defer choosing the configuration *and* the architecture until build time.<br>
<br>
No "CMake time" decisions are possible based on the configuration or the architecture with this approach because neither is known until compile time.<br>
<br>
It is inappropriate to "choose the configuration or architecture" in CMake code with this approach, and you should re-think about it and see if you can make compile time decisions instead, possibly with #ifdef sections in your C/C++ code...<br>
<br>
Rather than re-organize your libraries, you could easily just use "win32/libs/$(Platform)" as your value when using the VS generators, and this should work.<br>
<br>
<br>
By the way, Gilles, I echo the sentiment: nice work! I wish MS had gotten involved in CMake even earlier... but welcome!<br>
<br>
<br>
HTH,<br>
David C.<br>
<br>
<br>
</div></div></blockquote></div><br></div>