cmake-conan
cmake-conan copied to clipboard
Incorrect architecture for MSVC HostX64/ARM64/cl.exe cross-compiler
There seems to be a hard-coded assumption in conan.cmake that x86_64 is the only *64 architecture MSVC supports.
https://github.com/conan-io/cmake-conan/blob/7f9fe6df98eb805d78b7e55f27920546dbdd8d49/conan.cmake#L200-L201
This is not so; it has historically supported IA64 (until Visual Studio 2010), and today supports ARM64 and also an alternate calling-convention ARM64ec
Hi, Yes, there will be probably cases that will escape to the conan.cmake auto-detection but I think that for more specific cases the architecture should be passed as an argument because it would be challenging to cover all cases here.
I guess I would consider that an absolute last-resort, because the CMakeLists.txt has no real business knowing what architecture the user wants to compile for - that's up to their generator/toolset parameters (e.g. CMAKE_GENERATOR_PLATFORM).
I can certainly see the argument that things like ARM64 vs ARM64ec are too exotic to handle yet (though I suspect/hope that will not stay true - the Apple M1 is a formidable competitor and it's pretty clear Microsoft/Qualcom/etc are at least trying to answer it).
But there's only a limited set of things MSVC_${LANGUAGE}_ARCHITECTURE_ID can be, and the idea that everything containing "64" is x86_64 is just not true. Not having a guess for something too new - sure. Guessing in a way that is confidently incorrect seems much less OK.
Edit: more linkdumping - the original source of ARCHITECTURE_ID comes from CMakePlatformId.h.in
That said, this is just me making notes on the issue in a public place. I'm not trying to demand someone else fix it for me - if I get to where we're actively working on an arm64-windows port and blocked by this (instead of just feeling it out as a future possibility), I'll make a PR :-)
That said, this is just me making notes on the issue in a public place. I'm not trying to demand someone else fix it for me - if I get to where we're actively working on an arm64-windows port and blocked by this (instead of just feeling it out as a future possibility), I'll make a PR :-)
Thanks a lot for all the detailed information! It will be very useful to have this here in the future if we have time to improve the auto-detection or a PR is open for this.