[petsc-dev] CMake-assisted CUDA builds ready

Karl Rupp rupp at mcs.anl.gov
Wed Mar 20 15:19:23 CDT 2013


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





More information about the petsc-dev mailing list