https://bugs.kde.org/show_bug.cgi?id=460450
--- Comment #6 from Igor Kushnir <igor...@gmail.com> ---
Git commit 419d3a5de17134aadbb26edaf7a4b3a369af6567 by Igor Kushnir.
Committed on 22/01/2023 at 16:28.
Pushed by igorkushnir into branch 'master'.
cmake: improve detection of outdated project data
The current algorithm is simple: consider project data outdated if the
API reply index file was last modified before a possibly generated
source CMake file. Unfortunately this algorithm is unreliable:
1) does not detect source CMake file modifications made during a CMake
configure or generate step;
2) ignores CMakeCache.txt modifications.
Improvements in this commit:
1. Consider project data invalid if KDevelop's CMake file API client
query file does not exist. KDevelop never removes this file. The absence
of the client query file can mean that it has never been created, in
which case there can be no API reply; or it was removed during a prune
job, which should have removed the API reply as well; or it was removed
for some other reason, possibly an error.
2. Consider project data outdated if the API reply index file was last
modified before the API client query file. This means that a CMake
generate step was canceled - probably because of some error.
3. Consider project data outdated if the API reply index file was last
modified before CMakeCache.txt. This can mean that the user modified
CMakeCache.txt manually but did not run cmake afterwards, or run only a
CMake configure step, but not a CMake generate step, which updates the
API reply.
4. Consider project data outdated if the API client query file was last
modified before a non-generated source CMake file. A non-generated
source CMake file can be last modified between the API client query and
reply index files for two reasons:
1) the user edited a source CMake file during a CMake configure or
generate step, in which case project data is out of date;
2) the user edited a source CMake file, then run CMake configure and
generate steps outside of KDevelop, in which case project data is
up to date.
Since KDevelop cannot know the true reason, it should err on the side of
caution and consider project data outdated in this case. The user is not
supposed to edit generated CMake files, so ignoring their modifications
is safe enough. Generated CMake files can be modified during a CMake
configure step, which occurs after KDevelop creates the API client query
file.
5. Optimize by finishing CMake::FileApi::ImportJob as soon as it detects
that project data is out of date, if
ChooseCMakeInterfaceJob::tryDirectImport(), which discards outdated
data, creates the job.
Ignoring modifications to generated CMake files brings outdated project
data detection algorithm closer to the algorithm in
CMakeManager::integrateData(), which decides whether to reload a project
when a file is changed. The remaining and just introduced
inconsistencies between these two algorithms:
1. Modifications to external source CMake files make project data
outdated, but such modifications are not tracked. Watching each
individual external CMake file can be costly and cause issues elsewhere
if a watched item count limit is reached. QFileSystemWatcher's
documentation warns:
The act of monitoring files and directories for modifications consumes
system resources. This implies there is a limit to the number of files
and directories your process can monitor simultaneously.
External source CMake files can be modified when the user updates an
external dependency of a project opened in KDevelop, or when system
updates are installed. The user should be aware of both events and can
reload or reopen the project to reconfigure it, or restart KDevelop.
2. Modifications to CMakeCache.txt make project data outdated, but such
modifications are not tracked. Reloading the project after each
CMakeCache.txt change is risky. CMakeCache.txt can be modified during a
CMake configure step. If this CMake configure step occurs outside of
KDevelop, concurrent CMake configuration runs can corrupt build data.
Even if the CMake configure step that modifies CMakeCache.txt runs
inside KDevelop, reloading the project risks creating a reload loop.
When the user edits a source CMake file during a CMake configure or
generate step, KDevelop prints a kdevelop.plugins.cmake.debug message:
"the project is being reloaded, aborting reload!" but does not
reconfigure the project automatically for now. But at least with this
commit when KDevelop is restarted, it detects that project data is out
of date and reconfigures the project.
M +75 -8 plugins/cmake/cmakefileapi.cpp
M +14 -1 plugins/cmake/cmakefileapi.h
M +21 -16 plugins/cmake/cmakefileapiimportjob.cpp
M +6 -0 plugins/cmake/cmakefileapiimportjob.h
M +5 -3 plugins/cmake/cmakemanager.cpp
M +2 -2 plugins/cmake/tests/test_cmakefileapi.cpp
https://invent.kde.org/kdevelop/kdevelop/commit/419d3a5de17134aadbb26edaf7a4b3a369af6567
--
You are receiving this mail because:
You are watching all bug changes.
