[bug] x86 build reports CMAKE_SYSTEM_PROCESSOR=AMD64 and not i386

[KUGA2]

Describe the bug

Hi,

When buidling a x86 project (Have seen it on windows but based on my research probably also on other OS-es), the CMAKE_SYSTEM_NAME reports a 64 bit architecture.

Reason is this code exception here. CMAKE_SYSTEM_NAME is not set, therefore processor is neither set by conan nor by CMake internas. Note that CMake does only try to find the real TARGET processor name when CMAKE_SYSTEM_NAME is set, but always uses CMAKE_HOST_SYSTEM_PROCESSOR when it is not set.

This does not affect compilation results, but decisions made based on that variable (e.g. folder names).

Workaround:

• Set CMAKE_SYSTEM_NAME in profile or toolchain e.g: tools.cmake.cmaketoolchain:system_name=Windows
• (Optional) Disable CMAKE_CROSSCOPILING. Otherwise CMake will not try to execute your created binaries. See add_custom_command

Btw, a little rant about jargon. I dislike the conan build/host naming. It is really counterintuitive when coming from CMake only projects... Example:

conan	cmake
arch_build	CMAKE_HOST_SYSTEM_PROCESSOR
arch_host	CMAKE_SYSTEM_PROCESSOR

How to reproduce it

Run this example project and a windows x86 profile:

conanfile.py

from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout

class Recipe(ConanFile):
    name = "cmake_test"
    version = "1.0"
    settings = "os", "build_type"
    generators = "CMakeToolchain"
    
    def layout(self):
        cmake_layout(self)
        
    def build(self):
        cmake = CMake(self)
        cmake.configure()

CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(foo LANGUAGES NONE)
message(STATUS "CMAKE_SYSTEM_PROCESSOR: ${CMAKE_SYSTEM_PROCESSOR}")

profile

[settings]
arch=x86
os=Windows
...

[memsharded]

Hi @KUGA2

Thanks for your feedback.

I have done conan-io/conan#18075 to try to fix this. I think there were some (historical) reasons for this, but maybe it needs to be updated, lets see how it goes.

Btw, a little rant about jargon. I dislike the conan build/host naming. It is really counterintuitive when coming from CMake only projects... Example:

Well, Conan didn't create the naming, it is the GNU convention, it is impossible to align with all different namings out there. It would have been better if CMake would have gone the GNU convention, which I think is more intuitive:

• "build": the machine that "builds" the software
• "host": the machine that "host" the built software (and runs it)

[KUGA2]

I have done #18075 to try to fix this. I think there were some (historical) reasons for this, but maybe it needs to be updated, lets see how it goes.

Blazing fast as always :D Thank you.

Well, Conan didn't create the naming, it is the GNU convention, it is impossible to align with all different namings out there. It would have been better if CMake would have gone the GNU convention, which I think is more intuitive:

* "build": the machine that "builds" the software

* "host": the machine that "host" the built software (and runs it)

I did not know that! Maybe this helps me resolve my brain tangles in the future :)

[memsharded]

I have closed conan-io/conan#18075, please read the comments there, this implies that this wouldn't be a bug, but aligned with the CMake behavior.

[KUGA2]

Well ok. We rely pretty heavily on CMAKE_SYSTEM_PROCESSOR, so I i have to workaround myself then.

[memsharded]

From conan-io/conan#18075 (comment)

FFR No2: You most likely, if you set CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME, also want to set CMAKE_SYSTEM_VERSION. It is not automatically set by cmake when in crosscompiling mode and it is references in some packages. (Just witnessed issues with zeromq).

[MarcelRaad]

The current behavior without conan-io/conan#18075 also breaks CMake's NASM support on all platforms since CMake 3.30:
https://gitlab.kitware.com/cmake/cmake/-/commit/7cf45c9e6a7633cb231dfa07d8e7346200242af0#e7b689c4cea782b0089af944f149aa89e16510c6
For example on Linux, this leads to -f elf64 instead of -f elf being passed to NASM for 32-bit x86 builds.

conan-io/conan#18075 (comment) mentions CMake defaults as a reason for not moving forward with the change. I don't follow CMake development closely, so I cannot tell if this should be fixed in Conan as CMake now considers x86 64-bit to 32-bit a cross compile more widely, or if that part of the CMake commit is bad and should be reverted.

[jcar87]

Hi @MarcelRaad - could you please open a separate issue regarding the errors you are getting with NASM and CMake 3.30+ so that we can have a better look.
This issue (as well as conan-io/conan#18075) - pertain to Windows, where the long standing convention is a tad different (and defining it even if it looked "correct", introduced risks that would have altered the behaviour in different ways).