Changes between Initial Version and Version 1 of Ticket #41070


Ignore:
Timestamp:
Oct 31, 2013, 1:40:53 AM (11 years ago)
Author:
ryandesign (Ryan Carsten Schmidt)
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.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #41070

    • Property Cc ryandesign@… added
    • Property Summary changed from Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting in cmake to cmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting
    • Property Owner changed from macports-tickets@… to css@…
    • Property Keywords cmake removed
    • Property Port cmake added
  • Ticket #41070 – Description

    initial v1  
    11A test directory with a CMakeLists.txt with this one line:
     2{{{
    23message("-- Processor type        : ${CMAKE_HOST_SYSTEM_PROCESSOR}")
     4}}}
    35returns (among all the other info) when doing "cmake .":
     6{{{
    47-- Processor type        : i386
     8}}}
    59
    610However "uname -m" returns the correct x86_64 (on my MacBook Pro with i7 cpu).