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

[Peyton, Jonathan L]

>#1 What's the problem with this method? autocrap and cmake are likely doing compile time tests in the background that may not be obvious (I'm curious how it's definitively finding the size of a pointer)
>
>#2 by "clean" I meant that this cmake module abstracts away these details and just include it and done.. no need to deal with the if() spaghetti mess directly

Yeah, the more I think about it, this is probably the best way.  One nice feature about this way is it accommodates cross-compiling in a natural way by probing the compiler itself.  
I guess "clean" for me means to have CMake offer this functionality instead of each individual project hacking up their own solution (or borrowing from others).  They already probe the compiler
in a similar fashion for __COMPILER_TYPE_MACROS__  and test a dummy source file to make sure your toolchain is set up correctly to produce executables.

-- Johnny

-----Original Message-----
From: "C. Bergström" [mailto:cbergstrom at pathscale.com] 
Sent: Thursday, August 7, 2014 6:23 PM
To: Peyton, Jonathan L
Cc: Carlo Bertolli; openmp-dev at dcs-maillist2.engr.illinois.edu; Michael Wong; Cownie, James H
Subject: Re: [Openmp-dev] PPC64 patch from Intel's fourth cmake patch

On 08/ 8/14 04:46 AM, Peyton, Jonathan L wrote:
>> 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.
> I think it is a stretch to call this clean.  It is slick, but it relies on predefined compiler macros to detect the architecture on non-macosx operating systems.
> It creates a dummy C file with all the #if __ARCH_MACRO__, "compiles 
> and runs" it, then takes the stderr from the compiler output as the architecture.
#1 What's the problem with this method? autocrap and cmake are likely doing compile time tests in the background that may not be obvious (I'm curious how it's definitively finding the size of a pointer)

#2 by "clean" I meant that this cmake module abstracts away these details and just include it and done.. no need to deal with the if() spaghetti mess directly
>
>> llvm/clang may have something similar as well..
> LLVM uses uname indirectly.  I have dug through this a little, the calling sequence goes as follows for cmake:
> Top Level CMakeLists.txt --> (includes) cmake/config-ix.cmake --> 
> (includes) cmake/GetHostTriple.cmake --> (calls) get_host_triple() --> (calls) sh autoconf/config.guess --> (calls) uname The variable at interest is LLVM_NATIVE_ARCH.  It appears someone has already done the if() work (in autoconf/config.guess) for autoconf and LLVM uses that for non-Windows machines.
I'd need to look, but I'm a bit skeptical that cmake is calling autocrap to get this. If this is really the case then they can go to hell and we should certainly do it more cleanly. (Learning from the failures of others)

My feedback feels like I'm pushing a rock uphill, but I guess I should be happy I didn't have to look at M4...