[Openmp-dev] PPC64 patch from Intel's fourth cmake patch

["C. Bergström"]

On 08/ 7/14 06:07 AM, Peyton, Jonathan L wrote:
> C. Bergström, Carlo,
>
>>> ---------
>>> using uname to detect the host/target was rejected before. Please use
>>> the "cmake" way of detecting things.
>>> +EXECUTE_PROCESS( COMMAND uname -m COMMAND tr -d '\n' OUTPUT_VARIABLE
>>> DETECT_ARCH )
>>> +EXECUTE_PROCESS( COMMAND uname -m COMMAND tr -d '\n' OUTPUT_VARIABLE ARCH )
>>>
>> OK. I did some investigation on this and have done it again just now but was not able to find a way of doing this natively in cmake.
>> Actually, I found comments about how cmake does not support this natively (may be an old cmake version).
>> Can you suggest how to do this? (a link to a web page with an example is fine too).
> I have done some research on this topic.  You are both right :) .  There is a cmakey way to get at uname output, and this particular variable is CMAKE_HOST_SYSTEM_PROCESSOR which
> Is defined by uname -p (slightly different but seems to be preferred over uname -m for reasons I'm not sure).  You can actually see this in the standard cmake modules located at:
> /path/to/cmake_install_root/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake
>
> The problem with using this as an architecture detection mechanism: it is not standard.  Some systems will define uname -p as x86_64, amd64, x64, etc.  This information is embedded in the kernel, and I was not inclined to try to gather all possible values into a giant if() statement to determine if it was 64 bit x86 architecture (same for 32 bit x86).
>
> So if there is a need to put something like this back in, use the CMAKE_HOST_SYSTEM_PROCESSOR variable because it won't mess up Windows builds that don't even have uname to depend on.
Ok I didn't realize it was still such a pita.

Others appear to have solved this though
https://github.com/petroules/solar-cmake/blob/master/TargetArch.cmake

Seems to cleanly wrap the if() statements and provide a reliable way to 
detect what's needed. I do slightly question if it will be perfect for 
PPC64, but I guess it wouldn't be too hard to patch.

If this isn't sufficient I can keep looking or maybe give a hand fixing it.

llvm/clang may have something similar as well..