On 18. Nov, 2009, at 24:55 , Michael Jackson wrote:

On Nov 17, 2009, at 6:45 PM, Sean McBride wrote:

On 11/17/09 5:57 PM, Michael Jackson said:

cmake -DCMAKE_OSX_ARCHITECTURES='x86_64;i386' ../

Will throw the following error:

-- Check size of size_t
CMake Error at /Users/Shared/Toolkits/CMake-2.6.4/share/cmake-2.6/
Modules/CheckTypeSize.cmake:89 (MESSAGE):
CHECK_TYPE_SIZE found different results, consider setting
CMAKE_OSX_ARCHITECTURES or CMAKE_TRY_COMPILE_OSX_ARCHITECTURES to
one or no
architecture !
Call Stack (most recent call first):
ConfigureChecks.cmake:84 (CHECK_TYPE_SIZE)
CMakeLists.txt:34 (INCLUDE)

Which makes absolute sense. I am updating a legacy Expat build system to CMake and just hit this when I was trying to automate some builds.
If I run cmake without specifying CMAKE_OSX_ARCHITECTURES variable.
What are others doing in this situation. Obviously something has to be
reworked on my end.

Mike, are you reading my mind? I just noticed that CMake has those same
errors building itself!  See:
<http://public.kitware.com/Bug/view.php?id=9913>

This is new in 2.8.

--
____________________________________________________________
Sean McBride, B. Eng                 s...@rogue-research.com
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada



Maybe, that would be scary though. Basically I had to wrap the calls like this:

if (NOT APPLE)
   CHECK_TYPE_SIZE(long           MXA_SIZEOF_LONG)
   CHECK_TYPE_SIZE(size_t         MXA_SIZEOF_SIZE_T)
   CHECK_TYPE_SIZE(ssize_t        MXA_SIZEOF_SSIZE_T)
endif()

Then in the header file that gets configured I have this:

#if !defined(__APPLE__)
# define MXA_SIZEOF_CHAR   @MXA_SIZEOF_CHAR@
# define MXA_SIZEOF_SHORT  @MXA_SIZEOF_SHORT@
# define MXA_SIZEOF_INT    @MXA_SIZEOF_INT@
# define MXA_SIZEOF_LONG   @MXA_SIZEOF_LONG@
# define MXA_SIZEOF_FLOAT  @MXA_SIZEOF_FLOAT@
# define MXA_SIZEOF_DOUBLE @MXA_SIZEOF_DOUBLE@
#else
# define MXA_SIZEOF_CHAR   1
# define MXA_SIZEOF_SHORT  2
# define MXA_SIZEOF_INT    4
# if defined(__LP64__) && __LP64__
#  define MXA_SIZEOF_LONG  8
# else
#  define MXA_SIZEOF_LONG  4
# endif
# define MXA_SIZEOF_FLOAT  4
# define MXA_SIZEOF_DOUBLE 8
#endif

I think why it never gets hit is that everyone just builds CMake for a single arch, or they let CMake do the initial run, and then use the CMake-GUI to add an arch to the list. Just a guess. I guess someone can file a bug against cmake for that..

--
Mike Jackson <www.bluequartz.net>



Problem is, what should CMake do in the case of multiple CMAKE_OSX_ARCHITECTURES? sizeof(long) has possibly different values for each of the architectures! The same problem applies to detecting a 64-bit build with SIZEOF_VOID_P and similar stuff.

The correct thing to do is use exact-width integer types, such as int_64t, where possible and required. Otherwise, check for the __LP64__ and similar defines. Since gcc with multiple -arch flags compiles every file multiple times automatically, there's really nothing that CMake could do about. Except, one could propose to do it the complicated way of compiling every architecture separately and the using 'lipo' to glue the different libraries/executables together). But that doesn't help much, because then you probably have multiple config.h, each with different content, and don't know which of them to install. Of course, that could be solved the way Apple does it in /usr/ include/architecture, by having a "wrapper" header which includes the correct architecture-specific header depending, again, on some preprocessor defines. But that probably can't be handled by CMake in an automatic way, so it's again up to the programmer to do handle it all, which leaves us right where we left off... ;-)


Michael
_______________________________________________
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

Reply via email to