[CMake] Properly Detecting Win64

[James Bigler]

On Tue, Apr 12, 2011 at 1:27 PM, j s <j.s4403 at gmail.com> wrote:

>
>
> On Tue, Apr 12, 2011 at 2:13 PM, James Bigler <jamesbigler at gmail.com>wrote:
>
>> On Mon, Jan 17, 2011 at 11:27 AM, Michael Jackson <
>> mike.jackson at bluequartz.net> wrote:
>>
>>>
>>> On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote:
>>>
>>> > 2011/1/17 Michael Jackson <mike.jackson at bluequartz.net>:
>>> >> I have the following code:
>>> >>
>>> >> if ( "${CMAKE_SIZEOF_VOID_P}" EQUAL "8" )
>>> >>        set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-Win64")
>>> >> elseif( "${CMAKE_SIZEOF_VOID_P}" EQUAL "4" )
>>> >>        set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-Win32")
>>> >> else()
>>> >>        set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-Unknown")
>>> >> endif()
>>> >>
>>> >> I properly generate VS 2008 Win64 projects. Everything builds fine.
>>> When I build the "PACKAGE" project I get a zip file with "-Unknown" in the
>>> name. This will usually configure OK the first time or so, ie, I get a Zip
>>> file name with "-Win64" but after a few more configs this seems to revert
>>> back to "Unknown". Searching the "CMakeCache.txt" file for
>>> "CMAKE_SIZEOF_VOID_P" comes up empty. Is this some sort of temporary
>>> variable?
>>> >
>>> > Shouldn't be "temporary" just "not in cache".
>>> >
>>> >> Do I need to store it in my own cache variable somewhere?
>>> >
>>> > I don't think you should.
>>> > Looks like a bug to me, how come CMAKE_SIZEOF_VOID_P
>>> > would it be defined "sometimes" but not **always**...
>>> >
>>> > need to dive into the source of this definition, may be it is not
>>> always
>>> > defined because it is "indirectly" defined in the chain of CMake
>>> processing due
>>> > to CMake cache.
>>> >
>>> > By the way shouldn't you use
>>> >
>>> > if (CMAKE_SIZEOF_VOID_P EQUAL 8)
>>> >
>>> > instead of
>>> >
>>> > if ( "${CMAKE_SIZEOF_VOID_P}" EQUAL "8" )
>>> >
>>> > from the doc I think EQUAL is for values whereas STREQUAL is for
>>> string.
>>> >
>>> >
>>> > --
>>> > Erk
>>> > Membre de l'April - « promouvoir et défendre le logiciel libre » -
>>> > http://www.april.org
>>>
>>> It seems like if I start with a clean build directory then
>>> CMAKE_SIZEOF_VOID_P will be the proper value for the environment I am
>>> running in. But then after a while (many runs of CMake) the value seems to
>>> get "lost" or otherwise is NOT in the cache any longer. Kind of odd really.
>>>
>>> You are probably right about the improper use of the "if" command. I
>>> never really know which one to use and when something does not work when I
>>> _think_ it really *should* work then I start trying all sorts of stuff.
>>>
>>> Maybe someone else has some ideas as to why CMAKE_SIZEOF_VOID_P might not
>>> be defined.
>>> ___________________________________________________________
>>> Mike Jackson                      www.bluequartz.net
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> I've also seen this, and I would appreciate if anyone else who experiences
>> this could chime in, so that we might be able to start profiling situations
>> where this comes up.  I don't remember how I fixed the problem last time,
>> though.
>>
>> James
>>
>>
>
> Maybe you can base the package name by testing the generator name.  As for
> the pointer size, I use:
> IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
>
> Regards,
>
> Juan
>
>
Yeah, the problem is that CMAKE_SIZEOF_VOID_P's value disappears (i.e. as if
the variable hasn't been defined).  This would make that test fail
regardless of whether it was a 32 or 64 bit build.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110412/4bf61603/attachment.htm>