https://bugs.kde.org/show_bug.cgi?id=460450
--- Comment #4 from Milian Wolff <m...@milianw.de> ---
here's what I added to a project that I'm working on at work:
```
# prevent concurrent cmake runs which could fubar the cmake cache
# really, this should be handled directly in CMake, but for now we can
# at least prevent madness through this manual workaround
# this is required for developers who use IDEs that run cmake automatically
# to update the cache. if a build step is then run in an external terminal
# we could sometimes end up with two cmake processes writing to the cache file
# concurrently... which is a sure recipe for disaster
message(STATUS "Locking build directory ${CMAKE_CURRENT_BINARY_DIR}...")
file(LOCK ${CMAKE_CURRENT_BINARY_DIR} DIRECTORY GUARD PROCESS)
message(STATUS "Build directory locked...")
```
we could add something like this to at least ensure the second cmake configure
step waits for the first one to finish
I don't understand how your proposed handling of timestamps would help - we
would need to know when cmake is finished and only then could we start another
job. since that may happen externally too, we cannot really guard against that
only from within kdevelop? we might prevent multiple configure jobs running
concurrently from within kdevelop as a starter, which might help your
situation... but there would be easy ways to break that too
--
You are receiving this mail because:
You are watching all bug changes.
