[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