[CMake] OS X architecture changes interfere with CheckTypeSize()?

Michael Jackson mike.jackson at bluequartz.net
Wed Aug 11 13:03:01 EDT 2010


So basically you will "over ride" some of the values that get returned  
from those tests for OS X. Typically you end up with a "Configuration"  
file that has something like this in it:

#if !defined(__APPLE__)
/* The size of `size_t', as computed by sizeof. */
#define MXA_SIZEOF_SIZE_T

/* The size of `ssize_t', as computed by sizeof. */
#define MXA_SIZEOF_SSIZE_T

/* The size of `long', as computed by sizeof. */
#define MXA_SIZEOF_LONG

#else
    # if defined(__LP64__) && __LP64__
   #define MXA_SIZEOF_LONG 8
   #define MXA_SIZEOF_SIZE_T 8
   #define MXA_SIZEOF_SSIZE_T 8
   # else
   #define MXA_SIZEOF_LONG 4
   #define MXA_SIZEOF_SIZE_T 4
   #define MXA_SIZEOF_SSIZE_T 4
   # endif

#endif

and then you end up with a "Types.h" file with something like this in  
it:

/* Select a 64-bit integer type.  */
#if defined(MXA_TYPE_USE_LONG_LONG) && MXA_SIZEOF_LONG_LONG == 8
   #if !defined(_UINT64_T) && !defined(MXA_SIZEOF_UINT64_T)
   #define _UINT64_T
   typedef unsigned long long   uint64_t;
   #endif /* _UINT64_T */

   #if !defined(_INT64_T) && !defined(MXA_SIZEOF_INT64_T)
   #define _INT64_T
   typedef long long            int64_t;
   #endif /* _INT64_T */

   # define MXA_TYPE_UINT64 MXA_UNSIGNED_LONG_LONG
   # define MXA_TYPE_INT64 MXA_LONG_LONG

#elif MXA_SIZEOF_LONG == 8
   #if !defined(_UINT64_T) && !defined(MXA_SIZEOF_UINT64_T)
   #define _UINT64_T
   typedef unsigned long   uint64_t;
   #endif /* _UINT64_T */

   #if !defined(_INT64_T) && !defined(MXA_SIZEOF_INT64_T)
   #define _INT64_T
   typedef long            int64_t;
   #endif /* _INT64_T */
   # define MXA_TYPE_UINT64 MXA_UNSIGNED_LONG
   # define MXA_TYPE_INT64 MXA_LONG

#elif defined(MXA_TYPE_USE___INT64) && MXA_SIZEOF___INT64 == 8

   #if !defined(_UINT64_T) && !defined(MXA_SIZEOF_UINT64_T)
   #define _UINT64_T
   typedef unsigned __int64 uint64;
   #endif /* _UINT64_T */

   #if !defined(_INT64_T) && !defined(MXA_SIZEOF_INT64_T)
   #define _INT64_T
   typedef signed __int64   int64;
   #endif /* _INT64_T */

   # define MXA_TYPE_UINT64 MXA_UNSIGNED___INT64
   # define MXA_TYPE_INT64 MXA___INT64

#else
# error "No native data type can represent a 64-bit integer."
#endif

NOTE: this does NOT take into account compiling for the iPhone  
environment.

All of this is stored in a pair of files that get configured using  
"configure_file()" cmake command. Then in your code you explicitly use  
the types that you have defined above and all should work out when  
compiling on OS X with multiple Archs because the above files will  
control how the various ambiguous types get compiled. Which means that  
your source codes MUST at some point include these header files.
___________________________________________________________
Mike Jackson                      www.bluequartz.net
Principal Software Engineer       mike.jackson at bluequartz.net
BlueQuartz Software               Dayton, Ohio



On Aug 11, 2010, at 12:08 PM, Erik Lindahl wrote:

> Hi cmake-list,
>
> We've run into a minor problem when adapting our source code Gromacs  
> to use CMake for the default build environment.
>
> CMake 2.8 doesn't use any string for the default OS X architecture,  
> which on Snow Leopard is interpreted as the default x86_64.
> All the CheckTypeSize() tests then seem to run directly when e.g.  
> ccmake is invoked, and they thus set all SIZEOF_XXX defines to the  
> 64-bit values (e.g. 8 for "long int").
>
> Even if I set the architecture to "i386" the very first thing I do  
> in ccmake, the 64-bit values appear to be cached(?), and we then  
> happily continue to create a 32-bit build with 64-bit SIZEOF_XXX  
> values, which tends to break things in a hard way :-)
>
> If we use -DCMAKE_OSX_ARCHITECTURES=i386 on the command line when  
> starting a new build tree everything works fine.
>
>
> Is there any way we can work around this? My main worry is that  
> people will simply start ccmake, set the architecture, and then  
> produce a bad build without getting any warnings about it...
> (we tend to use i386 pretty frequently since we need to create  
> compatible versions for distributed computing).
>
>
> Cheers,
>
> Erik
>
> ----------------------------------------------------------
> Erik Lindahl <lindahl at cbr.su.se>
> Professor, Computational Structural Biology
> Center for Biomembrane Research & Swedish e-Science Research Center
> Department of Biochemistry & Biophysics, Stockholm University
> Tel: +468164675 Cell: +46703844534
>
> _______________________________________________
> 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