On Tue, Apr 12, 2011 at 1:27 PM, j s <[email protected]> wrote: > > > On Tue, Apr 12, 2011 at 2:13 PM, James Bigler <[email protected]>wrote: > >> On Mon, Jan 17, 2011 at 11:27 AM, Michael Jackson < >> [email protected]> wrote: >> >>> >>> On Jan 17, 2011, at 1:23 PM, Eric Noulard wrote: >>> >>> > 2011/1/17 Michael Jackson <[email protected]>: >>> >> 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
_______________________________________________ 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
