CMake project reloading.

[Olivier J. G.]

I've run into yet another bug that gets triggered by the reload that
happens when CMakeLists gets updated.
Create a class having a .cpp, and a .h, add it to CMakeLists.
Select both the .cpp and .h, right-click, remove.
Yes to remove from filesystem (for the .cpp, but it doesn't say)
Yes to remove from CMakeLists
Yes to the next remove from filesystem
*Crash*
When the cpp gets removed from the CMakeLists, cmake needs a reload,
which deletes the ProjectItem representing the .h, main thread tries
to remove the item, but it doesn't exist anymore.

I'm not just reporting a bug though, I know where to do that, and it's
likely a dupe anyhow. The real problem is this whole CMakeLists folder
doing a complete delete and reload cycle while other threads may still
be using those ProjectItems. There was at least one other nasty bug
that was caused by trying to access an item that was deleted by this
reload cycle, and probably a few. Fixing this bug would only be
working around the real problem...
I can see why an edit to CMakeLists would require a reload, since
there's no way to know if any of the items are still valid after a
change to it, but it sounds like there should be some thread-locking
for the use of ProjectItems so that things like this don't happen.
Furthermore, in any case, I think the projectFileManager interface
should expose removeFiles() rather than removeFile(). Otherwise you're
talking about reloading the project for each and every .cpp that gets
removed.
I would also think this should take a priority such that it gets done
before release, because it's a load of crashing bugs that won't stop
giving otherwise.

-Olivier JG