[CMake] Get Visual Studio target Arch

[Alexey Petruchik]

> No "CMake time" decisions are possible based on the configuration

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:

if (${CMAKE_SYSTEM_NAME} MATCHES "Windows")
    set(CMAKE_LIBRARY_PATH "win32/x86/lib")
endif()

find_package(A REQUIRED)
find_package(B REQUIRED)
find_package(C REQUIRED)

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 CMAKE_SYSTEM_PROCESSOR
 because its always defined to AMD64. 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
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 CMAKE_GENERATOR var and find
"Win64"\"ARM" substrings in it?

I'm really running out of ideas and will appreciate any help in this
question.

Regards, Alexey

On Wed, Sep 17, 2014 at 2:35 AM, Gilles Khouzam <
Gilles.Khouzam at microsoft.com> wrote:

> Hi David, Alexey
>
> 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.
>
> 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.
>
> 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.
>
> Looking forward to being able to help more.
>
> Gilles Khouzam
> Senior Development Lead
> Microsoft OSG
>
> -----Original Message-----
> From: David Cole [mailto:dlrdave at aol.com]
> Sent: Tuesday, September 16, 2014 03:37
> To: alexey.petruchik at gmail.com; Gilles Khouzam
> Cc: cmake at cmake.org
> Subject: Re: [CMake] Get Visual Studio target Arch
>
> > I still cant really make some arch specific ifdefs in my cmake scripts
> > using this approach.
>
>
> That's the point of a multi-configuration, multi-architecture Visual
> Studio solution: you defer choosing the configuration *and* the
> architecture until build time.
>
> No "CMake time" decisions are possible based on the configuration or the
> architecture with this approach because neither is known until compile time.
>
> 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...
>
> 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.
>
>
> By the way, Gilles, I echo the sentiment: nice work! I wish MS had gotten
> involved in CMake even earlier... but welcome!
>
>
> HTH,
> David C.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140917/55de1ac7/attachment.html>