[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