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.jack...@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 <s...@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 s...@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
_______________________________________________
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
