[CMake] Adding cross-compiler support to CMake ...

Brandon J. Van Every bvanevery at gmail.com
Mon Sep 11 13:06:31 EDT 2006


Sean McBride wrote:
> On 2006-09-08 14:40, Brandon J. Van Every said:
>
>   
>> Benjamin Reed wrote:
>>     
>>> On 9/6/06, Brandon J. Van Every <bvanevery at gmail.com> wrote:
>>>
>>>       
>>>> Actually it's not invalid to compile it.  That's what a cross-compiler
>>>> does.  It's invalid to run it.  CMake already has this distinction
>>>> between TRY_COMPILE and TRY_RUN, so if TRY_RUN is used inappropriately,
>>>> that's user error.  If CMake knows it's in some kind of
>>>> cross-compilation mode, it can disallow TRY_RUN and deliver an error.
>>>>         
>>> I don't know if this is what he meant, but at least as far as
>>> universal binaries are concerned, TRY_COMPILE *can* cause issues.
>>>
>>> For example, there are a number of autotool'd things that I have built
>>> as universal binaries which fail to build out of the box because they
>>> do:
>>>
>>> * checking endianness... big endian
>>>       
>> But that is a form of TRY_RUN.
>>     
>
> CMake's CMakeLists.txt has no TRY_RUN's and only one TRY_COMPILE.  Yet,
> when I build cmake with cmake I see the "checking endianness" message.
>   

You'd have to trace through everything to see what's ultimately used.  I 
didn't mean, "Endianness checks in CMake are implemented directly with 
TRY_RUN."  Nor indirectly; I have no idea.  I meant, "Conceptually, an 
Endinanness check must be implemented by compiling and running code."  
Either that or the compiler correctly defines the Endinanness for you 
somehow, and you query it somehow.

>   
>> You can't check endianness just by 
>> compiling something, you have to get a result back from running the 
>> program.  At least, I'm not thinking of any snippet of code that's 
>> portable, can be compiled on a little endian architecture, and not a big 
>> endian one.
>>     
>
>   

Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060911/22843a84/attachment.htm


More information about the CMake mailing list