CMake project reloading.

[Olivier J. G.]

> Hell no. I don't want another beast of the dimension of DUChain for the
> project tree. David already suggested a viable alternative: Don't store
> raw pointers to project items anywhere, except in the model itself (and
> thats not our code). He suggested that everybody else only keep a struct
> that has the path inside the model and when it tries to access something
> it fetches the actual item from the model. That way you can do effective
> null-pointer checks when actually using the item.
>
> The other option would be using a ref-counted class instead of raw
> pointers in the public API everywhere.

Think about the scenario I'm talking about though. Perhaps locking
isn't the best solution, I can't say I'm familiar with the internals,
but take the first solution...
.cpp file deleted, model starts a reload, BEFORE the model finishes
reloading, the next file comes around and asks for a proper
ProjectItem... "Sorry, the file you tried to delete no longer
exists".... until the project finishes reloading. Admittedly this in
combination with removeFiles should solve the problem, but still,
that's definitely gotcha behavior.
Second solution would have basically the same issue.
I would think some kind of task queue is in order for a robust solution.

> The steps you've described first are filed as bugreport already, the
> exact same steps. Yet we don't have any duplicates of that particular
> bug. There's the other way with the buildset trying to build an item
> that has been removed from the tree due to reloading, but that also is
> not hit very often.

And on one hand that's strange, because I had to run into it 3 times
before it peeved me enough to look into it. I think I know why this is
though, and that's that you can avoid it by deleting files one-by-one.
I imagine people are used to this behavior by now.
Also, I believe it's only recently that the .cpp and .h files were
sorted next to each other, thereby increasing the chance that someone
will select them both and try to delete them.

>
> So frankly, I don't see the need to invest the huge amount of work that
> any proper solution to the problem imposes for 1.0. Its completely
> inapropriate to start this at this point in the release cycle as a very
> big change that will destabilize KDevelop quite a bit. Hence we'd have
> to move the release date again and thats not something I'm willing to do
> for a problem that only very few people run into.

I completely agree on the delay point. My minor contributions are
motivated by desire to see KDevelop 4 finally released after all these
years. I was actually hoping someone would be able to simplify my
hypothesis into something that could  be done reasonably before
release. If you and everyone else feels that nothing can be done
without pushing back release, I'll be silent.

(But really now... deleting both the header and cpp at once an
unlikely thing to happen? Really?)

-Olivier JG