ValeevGroup/tiledarray

Parallel Compilation Error

ryanmrichard opened this issue · 8 comments

When I try to build TA in parallel I sometimes get the error:

fatal: destination path 'umpire-src' already exists and is not an empty directory.
[build] fatal: destination path 'umpire-src' already exists and is not an empty directory.
[build] CMake Error at umpire-ep-artifacts/Umpire-gitclone.cmake:31 (message):
[build]   Failed to clone repository: 'https://github.com/LLNL/Umpire.git'
[build] 
[build] 
[build] make[2]: *** [_deps/tiledarray-build/CMakeFiles/Umpire.dir/build.make:97: _deps/umpire-ep-artifacts/Umpire-download] Error 1
[build] make[1]: *** [CMakeFiles/Makefile2:2028: _deps/tiledarray-build/CMakeFiles/Umpire.dir/all] Error 2
[build] make[1]: *** Waiting for unfinished jobs....

it's nothing show stopping, as running build again fixes the problem, but thought I'd let you know.

I presume this is not standalone build of TA? Which revision of TA is this? did you use make? ninja?

Umpire is built using pure ExternalProject_add. So I don't think this is an issue with EP. If you are using recent TA then perhaps 51061e9 is the culprit?

This is the build of TA done by LibChemist, which looks like it's pinned to a somewhat old version 1b7e2e3. Let me try master and see if I still have the problem.

Looks like the error persists with master too.

I have been running into this too. For some reason, Umpire is trying to be built twice when the parallel builds happen. I think it may happen due to the separate Umpire-build and Umpire targets. At least, if I change the External-tiledarray dependency from Umpire-build to Umpire, I no longer get this error. I don't think that change affects any of the rest of the build because the Umpire target has a dummy install step.

Yea, this happens in MPQC too @evaleev - TA by itself is not an issue but how it interacts with being a subproject (this seems to be consistent with @awild82's observation)

@ryanmrichard you should check if this fixes the problem you were encountering, but the referenced PR fixes this problem for all instances I've encountered