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

Brandon J. Van Every bvanevery at gmail.com
Fri Sep 8 17:40:31 EDT 2006


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.  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.   So if we can't run the code, the cross-compiler has to 
report the target endianness to the host somehow, by some kind of 
declaration or query.  Now, a build API could have improper 
abstractions, and/or fail to document that certain things inevitably 
can't work because they're based on TRY_RUN.  But if the API has proper 
separation between TRY_COMPILE and TRY_RUN primitives, I'm not seeing 
the difficulty.  You turn off the TRY_RUN and say, "Sorry, Charlie.  We 
want tuna with great taste," or however that goes.


>
> if you're cross-compiling, you'll *still* get the wrong answer for
> half of the universal binary.  On Mac OS X, the proper thing to do is
> have your headers directly check for __BIG_ENDIAN__ and then things
> will be managed at compile-time depending on which half of the
> universal binary happens to be building at the time.

Well yeah, in other words it would be programmer error and not CMake 
error.  We can certainly have an educational mission, on the mailing 
list and hopefully in the docs (the poor docs).  So my question is how 
many portable, standard interfaces are out there for declaring things 
like __BIG_ENDIAN__ .  I haven't dealt with this sort of thing in awhile.


Cheers,
Brandon Van Every



More information about the CMake mailing list