Erik,
OS X is "special" because of all the platforms that CMake supports
it is the only one where you can compile for multiple architectures at
the same time. All the other platforms assume 1) you are compiling for
the platform you are running on or 2) you are cross compiling and you
have the appropriate platform definition files for CMake. OS X is a
mixture of both of those. The other thing you can do is to have your
own CheckTypeSize() that has logic to look for changes in the OS X
Architectures string in CMake and then rerun the tests when cmake is
run the next time. This will still ONLY get a single arch correct if
you are compiling for 2 archs (say i386 and x86_64) at the same time.
You could also detect more than a single arch in the
CMAKE_OSX_ARCHS and error out with a message stating that only a
single arch is supported at a time.
One thing is for sure though. If you ignore the fact that you NEED
these special #ifdefs your code may contain very subtle bugs that will
not be found until edge cases are hit by your users during runtime. OR
the inability to compile Universal Binaries of your code.
Really the things to look for you in your code are uses of "long" or
"size_t" in things like calculations where on 32 bit systems the value
would overflow. Or pointer math in some situations. Not sure what to
tell you. Most projects have something like this in them.
Cheers
--
Mike Jackson <www.bluequartz.net>
On Aug 11, 2010, at 1:31 PM, Erik Lindahl wrote:
Hi,
Thanks for the suggested workaround Mike!
However, that will get pretty cluttered when we add everything we
need for 50MB of source code... Our entire reason for moving from
autoconf CMake is to avoid having Windows as a "special case", so
we'd rather not exchange it for having OS X as a special case :-)
If the OS X architecture/s has/have to be set before starting CMake
(just as the compilers), wouldn't the natural solution be to ask the
user for it at the same time as the compilers, and then not make it
editable in the GUI/ccmake parameter list (In particular if there's
large risk of inconsistent results if you actually do edit it, which
I'd say the blank initial value is an invitation to :-)?
Cheers,
Erik
On Aug 11, 2010, at 7:03 PM, Michael Jackson wrote:
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 [email protected]
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 <[email protected]>
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
_______________________________________________
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
----------------------------------------------------------
Erik Lindahl <[email protected]>
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
