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

["C. Bergström"]

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...