CMake reload limits when multiple CMakeLists.txt files change in CLion 2023.2
0 reputation · 09 Jul 2020, 07:31 UTC
0 reputation · 09 Jul 2020, 07:31 UTC
CLion 2023.2 automatically triggers a CMake project reload whenever a CMakeLists.txt file is edited. When two or more such files are modified in quick succession, the IDE typically presents only one reload prompt, leaving the second file’s changes unprocessed. This behavior is documented under CMake project synchronization but remains unresolved for projects that rely on features such as C++20 modules.
The single-reload limitation can cause stale build configurations, especially on Windows where path normalization differences exacerbate the issue. Manual Reload CMake Project actions do not guarantee that all pending changes are applied if the CMake cache is corrupted.
CMakeLists.txt files?In CLion 2023.2 the IDE batches rapid changes to CMakeLists.txt files using a file‑watcher debounce (≈500 ms). When two or more such files are saved within that window only one Reload CMake Project prompt appears, so the second file’s changes may not be processed.
Reload CMake project on any file change (Settings → Build, Execution, Deployment → CMake) that disables batching and forces a reload per file.File → Invalidate Caches / Restart) is required to ensure a clean state after rapid multi‑file edits.The debounce window groups file‑system events. If the second CMakeLists.txt save occurs before the debounce timer expires, the IDE treats it as part of the same batch and issues a single reload. The reload may happen before the second save finishes, leaving its changes out of the CMake configuration, which is especially noticeable with C++20 modules or when path normalization differs on Windows.
CMakeLists.txt files.Reload CMake Project prompt appears.CMake → Show CMake Cache) for entries that should reflect the second file’s changes.File → Invalidate Caches / Restart, then reload again.If you do not see any reload prompt when editing a single CMakeLists.txt file, the file‑watcher may be disabled or excluded. In that case the batching behavior is not the cause, and you should verify that Help → Diagnostic Tools → Show Log… does not contain watcher‑related errors and that no .ignore patterns are blocking the files.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 09 Jul 2020, 18:17 UTC
One detail worth adding: the batching window isn't fixed. It's controlled by the internal registry property idea.filewatcher.delay (default ≈500 ms), adjustable via Help → Find Action → Registry. Lowering it makes two rapid saves of separate CMakeLists.txt files more likely to produce distinct reload prompts; raising it deliberately collapses them into one batch, which can actually be the safer workaround — edit both files, then let a single reload capture everything.
A practical verification on 2023.2: open Help → Diagnostic Tools → Show Log, search for FileWatcher and CMake model reloaded entries, and confirm that saves inside the delay window produce one reload log line while spaced saves produce two.
Caveat: don't push the delay below ~100 ms — on Windows the file-system event volume can trigger a reload prompt per save and noticeable UI lag. Exact registry key names may vary by build, so verify against your installation.