<div class="gmail_quote">On Wed, Apr 20, 2011 at 12:05 PM, j s <span dir="ltr"><<a href="mailto:j.s4403@gmail.com">j.s4403@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson<br>
<div class="im"><<a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a>> wrote:<br>
</div><div class="im">> 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.<br>
<br>
</div>I've always had very bad luck with the Visual Studio projects<br>
generator, and always start from a clean directory when something in<br>
the configuration changes. I only run the default configuration tests<br>
and I set the paths manually for all of my dependencies, so that saves<br>
some time.<br>
<br>
If I am just adding a source file, I can usually get away with not<br>
blowing everything away. However, I do close Visual Studio first,<br>
because of issues with the cmake scripts being run by the visual<br>
studio project. The cmake gui is typically sufficient for updating<br>
the build directory.<br>
<br>
Regards,<br>
<br>
Juan<br>
<div><div></div><div class="h5"><br>
<br>
> ___________________________________________________________<br>
> Mike Jackson <a href="http://www.bluequartz.net" target="_blank">www.bluequartz.net</a><br>
> Principal Software Engineer <a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a><br>
> BlueQuartz Software Dayton, Ohio<br>
><br>
> On Apr 20, 2011, at 11:52 AM, j s wrote:<br>
><br>
>> If it helps, I always configure from a clean directory. This script<br>
>> is written in bash for cygwin, but I'm sure it would be easy enough to<br>
>> do from some other script:<br>
>><br>
>> CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe<br>
>> mkdir win32<br>
>> (cd win32; "$CMAKE" -G "Visual Studio 10" ..)<br>
>> mkdir win64<br>
>> (cd win64; "$CMAKE" -G "Visual Studio 10 Win64" ..)<br>
>><br>
>> where ".." is my top level directory containing a CMakelists.txt. I<br>
>> have no problems then with:<br>
>> IF (WIN32)<br>
>> IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)<br>
>> ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)<br>
>> ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)<br>
>> ENDIF (WIN32)<br>
>><br>
>> in my files.<br>
>><br>
>> Juan<br>
>><br>
>> On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson<br>
>> <<a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a>> wrote:<br>
>>><br>
>>> On Apr 20, 2011, at 8:55 AM, David Cole wrote:<br>
>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Apr 19, 2011 at 5:44 PM, James Bigler <<a href="mailto:jamesbigler@gmail.com">jamesbigler@gmail.com</a>> wrote:<br>
>>>> On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com">bill.hoffman@kitware.com</a>> wrote:<br>
>>>> On 4/12/2011 4:13 PM, David Cole wrote:<br>
>>>><br>
>>>> Does somebody have reproducible steps to get to the point where<br>
>>>> CMAKE_SIZEOF_VOID_P disappears??<br>
>>>><br>
>>>> I've never seen that...<br>
>>>><br>
>>>> How many times do you have to re-configure before you start seeing this<br>
>>>> behavior? That sounds like something is just really wrong somewhere, and<br>
>>>> it would be a good thing to track down exactly what that is.<br>
>>>><br>
>>>> This variable is stored in this file:<br>
>>>><br>
>>>> CMakeFiles/CMakeCCompiler.cmake<br>
>>>><br>
>>>> It should not go away.<br>
>>>><br>
>>>> -Bill<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 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:<br>
>>>><br>
>>>> # Save compiler ABI information.<br>
>>>> SET(CMAKE_C_SIZEOF_DATA_PTR "")<br>
>>>> SET(CMAKE_C_COMPILER_ABI "")<br>
>>>><br>
>>>> IF(CMAKE_C_SIZEOF_DATA_PTR)<br>
>>>> SET(CMAKE_SIZEOF_VOID_P "${CMAKE_C_SIZEOF_DATA_PTR}")<br>
>>>> ENDIF(CMAKE_C_SIZEOF_DATA_PTR)<br>
>>>><br>
>>>> For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.<br>
>>>><br>
>>>> What could cause this to happen? Is there perhaps a race condition or some other failure when CMake detects this value?<br>
>>>><br>
>>>> James<br>
>>>><br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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?<br>
>>>><br>
>>>> What compiler/generator are you using in this instance?<br>
>>>> Does it repeat with a fresh build directory on this project in this environment? Or does it go away with a new fresh build?<br>
>>>><br>
>>>> Is the project that demonstrates this behavior public? (Can I try it here...?)<br>
>>>><br>
>>>> Thanks,<br>
>>>> David<br>
>>>><br>
>>> I have a small project (<a href="http://scm.bluequartz.net/eim/emmpm" target="_blank">http://scm.bluequartz.net/eim/emmpm</a>) 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.<br>
>>><br>
>>> 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:<br>
>>><br>
>>><br>
>>> -- Generating Copy Rule for Debug DLL Library C:/Developer/x64/tiff/bin/tif<br>
>>> -- Generating Copy Rule for Release DLL Library C:/Developer/x64/tiff/bin/t<br>
>>> -- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl<br>
>>> -- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl<br>
>>> -- CMAKE_SIZEOF_VOID_P:<br>
>>> CMake Warning at Resources/CPack/PackageProject.cmake:53 (if):<br>
>>> given arguments:<br>
>>><br>
>>> "EQUAL" "8"<br>
>>><br>
>>> Unknown arguments specified<br>
>>> Call Stack (most recent call first):<br>
>>> CMakeLists.txt:149 (include)<br>
>>><br>
>>><br>
>>> -- Configuring done<br>
>>> -- Generating done<br>
>>> -- Build files have been written to: C:/Users/mjackson/Workspace/emmpm/x64<br>
>>><br>
>>> And here is the cmake code that causes the issues:<br>
>>><br>
>>> if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8)<br>
>>> set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win64")<br>
>>> else()<br>
>>> set(CPACK_PACKAGE_FILE_NAME "${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win32")<br>
>>> endif()<br>
>>><br>
>>> Hope that helps<br>
>>> ___________________________________________________________<br>
>>> Mike Jackson <a href="http://www.bluequartz.net" target="_blank">www.bluequartz.net</a><br>
>>> Principal Software Engineer <a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a><br>
>>> BlueQuartz Software Dayton, Ohio<br>
>>> _______________________________________________<br>
>>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>>><br>
>>> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>><br>
>>> Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
>>><br>
>>> Follow this link to subscribe/unsubscribe:<br>
>>> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br><br>In my opinion, blowing away everything except for the CMakeCache.txt file is asking for trouble, and puts you in an invalid (or at the very least, unexpected) state. Because some of the cached values may depend on some of the stuff that was just blown away. If you're blowing everything else away, why not blow away CMakeCache.txt, too? Is the CMake configure that high a percentage of your total build time that saving a few minutes on the whole makes it worth trouble like this?<br>
<br>However, even so, I would like to understand and track down the source and the root cause of this trouble with CMAKE_SIZEOF_VOID_P -- because its correctness is arguably very important for many projects out there.<br>
<br>So -- if somebody has a way to reproduce this without blowing away everything except for the CMakeCache.txt, I'd still like to hear it.<br><br><br>Thanks,<br>David<br><br>