cmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting

[hjj@…]

A test directory with a CMakeLists.txt with this one line:

message("-- Processor type        : ${CMAKE_HOST_SYSTEM_PROCESSOR}")

returns (among all the other info) when doing "cmake .":

-- Processor type        : i386

However "uname -m" returns the correct x86_64 (on my MacBook Pro with i7 cpu). This is a big problem in our computational chemistry software development, where we use cmake to identify correct libraries, compilers, compiler flags etc. (project: ​http://daltonprogram.org) A colleague in USA suggests that we switch to homebrew to solve the problem of getting cmake to do the correct thing on both linux and darwin systems without dirty tricks, as testing for darwin and ports and then change explicitly to x86_64. I hope that I instead can persuade you to fix the problem.

[ryandesign (Ryan Carsten Schmidt)]

Are you saying that Homebrew's cmake correctly identifies the processor? Or that a cmake compiled from the official sources does so? I would rather expect this to be an upstream issue, if it is an issue at all (I don't know what the developers intend for CMAKE_SYSTEM_HOST_PROCESSOR to represent).

Note that "uname" does not necessarily tell you the best architecture to compile for, nor necessarily a valid architecture at all. On the PowerBook G4 I'm using today, "uname -m" says "Power Macintosh" whereas "uname -p" says "powerpc"; neither of those are valid PowerPC architectures (which would be something like "ppc" or "ppc7450"). On some early Intel Macs, "uname" might say "i386" because the computer uses a 32-bit kernel, while nevertheless being completely capable of running 64-bit usermode programs.

Why do you need to know the architecture? If you don't specify one, the compiler will use a reasonable default architecture.

[larryv (Lawrence Velázquez)]

Replying to hjj@…:

A colleague in USA suggests that we switch to homebrew to solve the problem of getting cmake to do the correct thing on both linux and darwin systems without dirty tricks, as testing for darwin and ports and then change explicitly to x86_64. I hope that I instead can persuade you to fix the problem.

No. The problem is that you are using CMAKE_HOST_SYSTEM_PROCESSOR incorrectly.

If you are not cross-compiling, CMAKE_HOST_SYSTEM_PROCESSOR ​is equivalent to CMAKE_SYSTEM_PROCESSOR, which is ​defined to be the output of uname -p on *nix systems, not uname -m. On my 10.8.5 machine:

% /usr/bin/uname -p
i386

If CMAKE_HOST_SYSTEM_PROCESSOR does not provide the information you require, then you need to find another way of obtaining that information.