[CMake] Properly Detecting Win64

[Michael Jackson]

On Apr 20, 2011, at 8:55 AM, David Cole wrote:

> 
> 
> On Tue, Apr 19, 2011 at 5:44 PM, James Bigler <jamesbigler at gmail.com> wrote:
> On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> On 4/12/2011 4:13 PM, David Cole wrote:
> 
> Does somebody have reproducible steps to get to the point where
> CMAKE_SIZEOF_VOID_P disappears??
> 
> I've never seen that...
> 
> How many times do you have to re-configure before you start seeing this
> behavior? That sounds like something is just really wrong somewhere, and
> it would be a good thing to track down exactly what that is.
> 
> This variable is stored in this file:
> 
> CMakeFiles/CMakeCCompiler.cmake
> 
> It should not go away.
> 
> -Bill
> 
> 
> 
> I just had this happen to one of my colleagues with a fresh build directory.  When I looked into CMakeCCompiler.cmake this is what I found:
> 
> # Save compiler ABI information.
> SET(CMAKE_C_SIZEOF_DATA_PTR "")
> SET(CMAKE_C_COMPILER_ABI "")
> 
> IF(CMAKE_C_SIZEOF_DATA_PTR)
>   SET(CMAKE_SIZEOF_VOID_P "${CMAKE_C_SIZEOF_DATA_PTR}")
> ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
> 
> For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
> 
> What could cause this to happen?  Is there perhaps a race condition or some other failure when CMake detects this value?
> 
> James
> 
> 
> If it is a race condition that simply occurs "sometimes, sproadically" then we should be able to reproduce this by writing a script that tries to configure a project over and over again into a clean directory.
> 
> But I'm not convinced it's as simple as that. There must be something happening (or some condition on certain machines/platforms/compilers) that triggers it... otherwise, we'd see this on the CMake dashboard results sometimes, wouldn't we?
> 
> What compiler/generator are you using in this instance?
> Does it repeat with a fresh build directory on this project in this environment? Or does it go away with a new fresh build?
> 
> Is the project that demonstrates this behavior public? (Can I try it here...?)
> 
> Thanks,
> David
> 
 I have a small project (http://scm.bluequartz.net/eim/emmpm) that I can reproduce on. If you do a checkout you will need to do a git clone --recursive due to the use of git submodules. It also depends on libTiff. This is what I do to reproduce the issue.

On Windows 7 x64 (Ultimate in my case) running from a MSVC Command Prompt x64 I invoke cmake-gui.exe and configure the project for Visual Studio 9 2008 x64. Configure and then generate. Close CMake-GUi.exe. Out in Windows explorer navigate to the build directory and delete EVERYTHING except CMakeCache.txt. I then run cmake.exe from the build directory from the same command prompt as I invoked cmake-gui.exe from. I now get the following error:


-- Generating Copy Rule for Debug DLL Library C:/Developer/x64/tiff/bin/tif
-- Generating Copy Rule for Release DLL Library C:/Developer/x64/tiff/bin/t
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- CMAKE_SIZEOF_VOID_P:
CMake Warning at Resources/CPack/PackageProject.cmake:53 (if):
  given arguments:

    "EQUAL" "8"

  Unknown arguments specified
Call Stack (most recent call first):
  CMakeLists.txt:149 (include)


-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/mjackson/Workspace/emmpm/x64

And here is the cmake code that causes the issues:

if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8)
    set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win64")
else()
    set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win32")
endif()

Hope that helps
___________________________________________________________
Mike Jackson                      www.bluequartz.net
Principal Software Engineer       mike.jackson at bluequartz.net 
BlueQuartz Software               Dayton, Ohio