[CMake] Testing the size of long throws error when more than one OS X Arch is passed

[Michael Wild]

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                 sean at 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