#41070: cmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting ---------------------+------------------- Reporter: hjj@… | Owner: css@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: cmake | ---------------------+------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) * owner: macports-tickets@… => css@… * keywords: cmake => * port: => cmake Old description:

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.

New description: 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. -- Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/41070#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#41070: cmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting ---------------------+---------------------- Reporter: hjj@… | Owner: css@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: cmake | ---------------------+---------------------- Changes (by larryv@…): * status: closed => reopened * resolution: invalid => -- Ticket URL: <https://trac.macports.org/ticket/41070#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X