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, construction. 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?