Hi Jed, On 03/20/2013 02:09 PM, Jed Brown wrote: > > On Wed, Mar 20, 2013 at 2:03 PM, Karl Rupp <rupp at mcs.anl.gov > <mailto:rupp at mcs.anl.gov>> wrote: > > I also found that in some occasions one should issue > >gt; rm -rf PETSC_ARCH/CMake* > prior to running a reconfigure in order to circumvent a bug [1] in > CMake. > > @Jed, Matt: The current cmakeboot.py removes > PETSC_ARCH/CMakeFiles/{__version_string}, which does not seem to > even exist on my machine (CMake 2.8.7). Can we instead just delete > the whole CMakeFiles-folder and probably CMakeCache.txt? > > > AFAIK, the bug did not exist in earlier versions of CMake. I don't want > to delete all of CMakeFiles because it implies that _everything_ would > have to be recompiled after re-running cmakeboot.py.
Yes, I know that this is a heavy operation. On the other hand, it only occurs after a reconfigure, so it's not supposed to happen too often. Anyway, with CUDA enabled I can deterministically reproduce the error in `next`: $> rm -rf PETSC_ARCH/CMake* $> PETSC_ARCH/conf/reconfigure-xxx.py # Fine, generates CMake build $> PETSC_ARCH/conf/reconfigure-xxx.py # Fine, generates CMake build $> make ... all # compiles $> PETSC_ARCH/conf/reconfigure-xxx.py # Hangs, legacy fallback However, the problem does not show up without CUDA. > Did you encounter another bug or just the one cited? I don't know yet what precisely is causing the problem. It may also be due to FindCUDA.cmake. > BTW, what sort of project introduces an infinite-loop bug in a subminor > release and then is incredulous that you would expect to be able to run > the tool more than once? How dare you actually try to really *use* the tool? ;-) Best regards, Karli