Fix attempt

At this commit a changed build directory or a preprocessor definition
may cause a lot of reparsing - much more than before. But on the other
hand, even in the already open files, the preprocessor definition code
highlighting is not stale. Plus there is no extra work doing full
reloadModel() (the project no longer disappears, then reappears in the
Projects tool view list).

Note that when a file is closed, then opened after a CMake config
change, both this branch and the current master highlight it correctly.
In case of an open file, the master-branch version requires any change,
even without saving, to the file in order for it to be reparsed with
proper highlighting.

If, however, no reloading is done at all, even changing and saving the
document won't highlight according to the current preprocessor
definition. The smaller amount of work that achieves the same effect is
done in the first+second commit of the last 3 (the user needs to change
CMake config, then press the Reload button in the project's context menu
in Projects view; but of course, this can and should be automated after
each CMake config change). The advantage of this smaller amount of work
is obvious - faster and easier on memory - less useless deletion,

Question: why doesn't CMakeManager detect and react to CMakeCache
changes automatically with help of KDirWatch? Probably should detect
such changes in CMakeCache via CMake::FileApi and reload only then. The
simplest way is to not dismiss a change in a cache file as a generated
file change in the existing lambda connected to KDirWatch::dirty(). But
maybe there is a cleaner way to handle this than adding an exception to
the isGenerated check. How does Qt Creator deal with CMake cache
changes? (both from inside Qt Creator and via CMake CLI/GUI). Ideally no
reloading should be scheduled from CMakePreferences::configure(). Do we
need to add support for this in the obsolete CMakeServer code path?
Status Job ID Name Coverage
passed #79326
linux kf5-qt5 qt5.12