[CMake] [Insight-developers] 64 bit build detection
Michael Wild
themiwi at gmail.com
Sat Jun 20 09:36:31 EDT 2009
True, must have missed this when sifting through "gcc -dM -E -arch ppc
- < /dev/null"...
But then, I just recently learned that it would be even better to use
#cmakedefine01 (which somehow didn't make it into the docs...):
#if !defined(__APPLE__)
#cmakedefine01 HOST_BIGENDIAN
#else
# if defined(__BIG_ENDIAN__)
# define HOST_BIGENDIAN 1
# elif defined (__LITTLE_ENDIAN__)
# define HOST_BIGENDIAN 0
# else
# error "Unknown HOST_BIGENDIAN!"
# endif
#endif
On 19. Jun, 2009, at 20:04, Michael Jackson wrote:
> Just to follow up with this, according to Apple's Universal Porting
> guide when figuring out if the system is big or little endian you
> should NOT test for the type of processor but rather have something
> like the following:
>
> #if !defined(__APPLE__)
> #define HOST_BIGENDIAN @HOST_BIGENDIAN@
> #else
> # if defined(__BIG_ENDIAN__)
> # define HOST_BIGENDIAN 1
> # elif defined (__LITTLE_ENDIAN__)
> # define HOST_BIGENDIAN 0
> # else
> # error "Unknown HOST_BIGENDIAN!"
> # endif
> #endif
>
>
> And _now_ the hoarse is officially beaten..
NOW it is beaten ;-)
> _________________________________________________________
> Mike Jackson mike.jackson at bluequartz.net
> BlueQuartz Software www.bluequartz.net
> Principal Software Engineer Dayton, Ohio
>
>
>
> On Jun 14, 2009, at 4:05 PM, Michael Wild wrote:
>
>> On Mac OS X one shouldn't do this kind of detection during
>> configure step, because as has been mentioned a single file can be
>> compiled multiple times for different architectures during one
>> single compiler invocation. The size of void* and even endianness
>> can change. It is preferable to have a central config.h.in (or
>> similar) containing something like this:
>>
>> #if defined(__APPLE__)
>> # if defined(__i386__)
>> # undef HAVE_64_BIT
>> # undef HAVE_BIG_ENDIAN
>> # elif defined(__ppc__)
>> # undef HAVE_64_BIT
>> # define HAVE_BIG_ENDIAN
>> # elif defined(__x86_64__)
>> # define HAVE_64_BIT
>> # undef HAVE_BIG_ENDIAN
>> # elif defined(__ppc64__)
>> # define HAVE_64_BIT
>> # define HAVE_BIG_ENDIAN
>> # else
>> // oops
>> # error "Unknown architecture!"
>> # endif
>> #else
>> # cmakedefine HAVE_64_BIT
>> # cmakedefine HAVE_BIG_ENDIAN
>> #endif
>>
>>
>> On NOT APPLE platforms you do the normal thing in your
>> CMakeLists.txt:
>>
>> if( NOT APPLE )
>> # check 64 bit
>> if( CMAKE_SIZEOF_VOID_P EQUALS 4 )
>> set( HAVE_64_BIT 0 )
>> else( CMAKE_SIZEOF_VOID_P EQUALS 4 )
>> set( HAVE_64_BIT 1 )
>> endif( CMAKE_SIZEOF_VOID_P EQUALS 4 )
>>
>> # check endianness
>> include( TestBigEndian )
>> test_big_endian( HAVE_BIG_ENDIAN )
>> if( HAVE_BIG_ENDIAN )
>> set( HAVE_BIG_ENDIAN 1 )
>> else( HAVE_BIG_ENDIAN )
>> set( HAVE_BIG_ENDIAN 0 )
>> endif( HAVE_BIG_ENDIAN )
>> endif( NOT APPLE )
>>
>> # configure config.h
>> configure_file( ${CMAKE_SOURCE_DIR}/config.h.in ${CMAKE_BINARY_DIR}/
>> config.h )
>> include_directories( ${CMAKE_BINARY_DIR} )
>>
>>
>> HTH
>>
>> Michael
>>
>> On 12. Jun, 2009, at 15:01, David Cole wrote:
>>
>>> CMake does not warn.
>>> And actually, I think I have to back-track on my statement a
>>> little bit.
>>>
>>> Whether or not a TRY_COMPILE "works" for a multiple arch / config
>>> build
>>> *depends* entirely on what you are trying to compile and what
>>> result you are
>>> expecting to get out of it. If you do a try compile on some code
>>> to detect
>>> the presence of a function, for example, that should work fine on a
>>> universal binary build (presuming the function you're trying to
>>> link against
>>> is present in universal binary form in the library it lives in...).
>>>
>>> The thing that won't work on a multiple arch/config build is
>>> trying to
>>> detect the size of something or the presence/absence of something
>>> where the
>>> thing you're trying to measure is different in the different archs /
>>> configs. If it's uniform across all archs/configs then you can
>>> measure it
>>> and get an answer that makes sense for all archs/configs. If not,
>>> then you
>>> can't.
>>>
>>> Does that make sense?
>>>
>>> So... CMake does not warn because it does not know whether what
>>> you are
>>> attempting to measure is valid or not. It's up to you to "do the
>>> right
>>> thing" in these sorts of situations.
>>>
>>> You already know that if you are building a universal binary with
>>> both
>>> 32-bit and 64-bit architectures in it that it makes no sense to
>>> "measure"
>>> the size of "void*" at CMake time. You know this because you know
>>> there is
>>> more than one answer depending on which one runs.
>>>
>>>
>>> Hope this clarifies things even further, (rather than muddying
>>> anybody's
>>> waters...)
>>>
>>> David
>>>
>>>
>>> On Thu, Jun 11, 2009 at 6:56 PM, Sean McBride <sean at rogue-research.com
>>> >wrote:
>>>
>>>> On 6/11/09 5:25 PM, David Cole said:
>>>>
>>>>> TRY_COMPILE works fine for cross compiles, just not for *mutiple
>>>>> configs/architectures "simultaneously"* compiles...
>>>>
>>>> Thanks for the clarification, that language is clearer.
>>>>
>>>> Does CMake detect and warn in such cases? (it is after all the
>>>> common
>>>> case on OS X.)
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> ____________________________________________________________
>>>> Sean McBride, B. Eng sean at rogue-research.com
>>>> Rogue Research www.rogue-research.com
>>>> Mac Software Developer Montréal, Québec, Canada
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
More information about the CMake
mailing list