[CMake] Properly Detecting Win64

Wed Apr 20 11:55:40 EDT 2011

I normally do this also BUT sometimes I try to short circuit the process because I just want to regenerate the Solution/Projects and not have to wait for a complete CMake configuration which takes a really long time on some project due to the number of tests that need to be performed. At the time this seems like a reasonable approach, just blow away everything except the cache and let cmake regenerate everything else. Now I know this really isn't a good idea. So maybe a bug maybe an "operator" error.
___________________________________________________________
Mike Jackson                      www.bluequartz.net
Principal Software Engineer       mike.jackson at bluequartz.net 
BlueQuartz Software               Dayton, Ohio

On Apr 20, 2011, at 11:52 AM, j s wrote:

> If it helps, I always configure from a clean directory.  This script
> is written in bash for cygwin, but I'm sure it would be easy enough to
> do from some other script:
> 
> CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
> mkdir win32
> (cd win32; "$CMAKE" -G "Visual Studio 10" ..)
> mkdir win64
> (cd win64; "$CMAKE" -G "Visual Studio 10 Win64" ..)
> 
> where ".." is my top level directory containing a CMakelists.txt.  I
> have no problems then with:
> IF (WIN32)
> IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
> ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
> ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
> ENDIF (WIN32)
> 
> in my files.
> 
> Juan
> 
> On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
>> 
>> 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
>> _______________________________________________
>> 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