bootstrap.py writes presets into CMakeUserPresets.json and generates IDE run configurations from/for them in with many conventions (VS, VSCode, Jetbrains, justfile). Nothing records which presets bootstrap put there, so a preset that is no longer wanted cannot be removed. The list only grows.
Problem
Bootstrap creates a preset named <build-type>-<os>-<compiler> for the configuration it just set up, and writes it to CMakeUserPresets.json (create_cmake_presets, called from utils/bootstrap/src/installer.py). The IDE run configurations are generated from the presets it finds (load_preset_names in utils/bootstrap/src/configs/justfile.py reads them back out of CMakeUserPresets.json).
Because the file is the only record, and it mixes presets bootstrap created with anything a user added by hand, the tooling cannot tell them apart. So it never removes anything. Run bootstrap with a different compiler, or a different build type, and both presets stay forever, along with their run configurations.
refresh_ide_configs.py works around it by guessing: it picks the preset whose build/<preset>/ directory was modified most recently.
The code involved is utils/bootstrap/src/presets/, utils/bootstrap/src/configs/justfile.py, and utils/bootstrap/refresh_ide_configs.py. The bootstrap tooling has Python unit tests under utils/bootstrap/tests/, registered as the utils-bootstrap-tests ctest, with a coverage floor enforced in CI.
Proposed solution
Something records which presets bootstrap initialized, so bootstrap can add to that set and remove from it.
Where that record lives is the open question, and it is most of the work in this issue:
- A marker inside each preset entry in
CMakeUserPresets.json, for example a vendor field naming bootstrap as the owner. Keeps everything in one file and stays valid CMake presets JSON. A user editing the file by hand can still confuse it.
- A separate state file under
build/ listing what bootstrap created. Clean separation, one more file to keep in sync with reality.
- Deriving it from what exists on disk, meaning the
build/<preset>/ and install/<preset>/ directories bootstrap creates. No extra state, but it cannot tell a preset bootstrap made from one a user configured by hand into the same layout.
Once the record exists, bootstrap should be able to drop a preset it no longer produces, along with its run configurations.
Whatever the record turns out to be, it must never delete a preset a user wrote by hand.
bootstrap.pywrites presets intoCMakeUserPresets.jsonand generates IDE run configurations from/for them in with many conventions (VS, VSCode, Jetbrains, justfile). Nothing records which presets bootstrap put there, so a preset that is no longer wanted cannot be removed. The list only grows.Problem
Bootstrap creates a preset named
<build-type>-<os>-<compiler>for the configuration it just set up, and writes it toCMakeUserPresets.json(create_cmake_presets, called fromutils/bootstrap/src/installer.py). The IDE run configurations are generated from the presets it finds (load_preset_namesinutils/bootstrap/src/configs/justfile.pyreads them back out ofCMakeUserPresets.json).Because the file is the only record, and it mixes presets bootstrap created with anything a user added by hand, the tooling cannot tell them apart. So it never removes anything. Run bootstrap with a different compiler, or a different build type, and both presets stay forever, along with their run configurations.
refresh_ide_configs.pyworks around it by guessing: it picks the preset whosebuild/<preset>/directory was modified most recently.The code involved is
utils/bootstrap/src/presets/,utils/bootstrap/src/configs/justfile.py, andutils/bootstrap/refresh_ide_configs.py. The bootstrap tooling has Python unit tests underutils/bootstrap/tests/, registered as theutils-bootstrap-testsctest, with a coverage floor enforced in CI.Proposed solution
Something records which presets bootstrap initialized, so bootstrap can add to that set and remove from it.
Where that record lives is the open question, and it is most of the work in this issue:
CMakeUserPresets.json, for example a vendor field naming bootstrap as the owner. Keeps everything in one file and stays valid CMake presets JSON. A user editing the file by hand can still confuse it.build/listing what bootstrap created. Clean separation, one more file to keep in sync with reality.build/<preset>/andinstall/<preset>/directories bootstrap creates. No extra state, but it cannot tell a preset bootstrap made from one a user configured by hand into the same layout.Once the record exists, bootstrap should be able to drop a preset it no longer produces, along with its run configurations.
Whatever the record turns out to be, it must never delete a preset a user wrote by hand.