Hold or freeze on the CMake Tools Extension

[sj-raima]

Brief Issue Summary

Background. We have a large project where we generate the CMake files and other files. The script that does this can set up the project in many different ways. It is common that we switch between different setups and we also regularly run this script when the source is updated from our SCM.

Behavior: If we generate the CMake files while VS Code is open, files often gets corrupted and the project behaves in various strange ways. The workaround is to always close VS Code, run the script, and start VS Code again. This is inconvenient and sometimes we forget to close VS Code.

Question: Is there a way for this extension to not run CMake (or whatever else is handling this) when we generate the CMake files without closing VS Code? Could we simply delete the top level CMakeLists.txt file, write all the other files, and recreate the top level CMakeLists.txt file last (maybe atomically through a rename)?

Suggestion: If there is no such mechanism, one solution is to implement a command line option to VS Code that can place a request with VS Code to hold/freeze/lock the extension for the workspace and similarly to release it. Such a mechanism need to take into account that VS code may not be running or VS Code exits while a hold is in place.

Usage: Our script would place a request with VS Code to hold/freeze/lock the extension for the workspace. Generate the CMake files. Release the hold with VS Code when we are done.

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

Some related issues are #3994 #3963 #3930

[gcampbell-msft]

@sj-raima Does it work as expected if you toggle the cmake.configureOnEdit setting? Or even the cmake.automaticReconfigure setting?

Thanks

[sj-raima]

@gcampbell-msft I unchecked both of them and reran my scripts to regenerate these files without closing VS Code and observed that it failed to find some presets.

I did a second test and this time it did not complain about any of the presets, but it would not build at all when I hit the build button.

We have about 100 configure presets, and for each of them about 30 build presets and 30 package presets. This is distributed among about 10 different files that are included from a main file. It takes quite a bit of time for CMake Tools to scan them.

Closing VS Code and reopening it always work.

I am on Linux.

[sj-raima]

@gcampbell-msft I can add that this is observed by other developers on our team as well. They are using it on Linux, Windows (VM) and wsl2.

[sj-raima]

Another suggestion would instead be to have the extension pop up a message "CMake file(s) changed externally, scan NOW?" and wait for the user to clear the message. This window could go away after a configurable amount of time if no changes have been detected to any of the CMake files.

[gcampbell-msft]

@sj-raima I do believe that you would still need to configure with the CMake Tools extension manually after running your script. However, turning off that setting should avoid the corruption issue that you were seeing.

Is it possible for you to attach your repro project so that we can reproduce, test, and investigate?

[sj-raima]

@gcampbell-msft This is a private repository. I will create a separate one with mostly empty files and hopefully be able to reproduce the issue that way. This will take a little time since there are other tasks that has priority.

[sj-raima]

@gcampbell-msft I have created a gziped tarball of about 5M bytes to reproduce this. Can I email that to you or do you require this to be uploaded to a public repository? For a public repository I need approval from my manager.

You can email me at sverre.johansen with an '@' and raima.com if you do not want to give out your email address here.

[sj-raima]

@gcampbell-msft Access to the full source has been emailed from my manager.

1. Check out the monza branch.
2. Please see the docker/ubuntu-22.04-gcc-11/Docerfile for packages needed. Pay special attention to Perl modules and jq.
3. Steps I followed to reproduce follows

$ perl prebuild.pl -p rdm_core

$ code .

$ perl prebuild.pl -p rdm_enterprise
$ perl prebuild.pl -p rdm_core
$ perl prebuild.pl

Run the prebuild script with different parameters similar to what was shown above. The presetController will sometimes report missing presets. It may also report that a preset change is already in progress. VS Code may also become unresponsive where the presetController seems to enter into an infinite loop. Whether the problem is in the presetController, somewhere else, or a combination thereof is unknown.

An alternative to fixing the extension could be to rewrite prebuild:

1. Delete or rename the top level CMakeLists.txt file before updating any of the CMakeLists.txt files and then update all the CMakeLists.txt files (including presets and other files) and rename the main CMakeLists.txt
2. Same as (1) but also do this for the preset.
3. Never write files directly, but instead write to a temporary file followed by a rename.
4. Write or rename files in a different order

[gcampbell-msft]

@sj-raima Perfect, thanks for the repro steps, we will get to it as soon as we can, but we appreciate your patience during the holidays.