[MacPorts] #41070: cmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting (was: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting in cmake)

[MacPorts]

#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