[Openmp-dev] PPC64 patch from Intel's fourth cmake patch
"C. Bergström"
cbergstrom at pathscale.com
Wed Aug 6 19:04:40 PDT 2014
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..
More information about the Openmp-dev
mailing list