Microsoft’s latest CMake Tools update is aimed at a problem C++ developers know well: too many small context switches between source code, build configuration, tests, cache settings and the terminal.
In the September 25 CMake Tools 1.24 release overview, Microsoft says the VS Code extension can now run and debug discovered CTest tests directly from source, preserve local cache edits as user-preset overrides, and help keep supported CMakeLists.txt source lists synchronized when files are created or deleted.
CTest moves closer to the line of code you are editing
Discovered CTest tests with resolved source locations can now expose Run and Debug CodeLens actions inside the editor. Selecting Run builds the executable target associated with that test and its dependencies, then executes the selected test without forcing the developer into a separate testing view.
That distinction matters in larger projects. If one test belongs to a small executable target, CMake Tools can build that target instead of rebuilding an unrelated default target. The result is a tighter edit-build-test cycle, especially in projects split across many translation units following normal C++ source-code conventions.
The Debug path behaves differently: Microsoft notes that the executable should already be built and an appropriate C++ debugger/debug adapter must be available. Debugging from the Project Outline or Testing view does not require a separate launch.json for the test.
Local cache changes no longer have to fight shared presets
A common CMake problem appears when a developer manually changes a cache value that is also defined by a shared configure preset. The next configure can overwrite the local change because the preset remains the authoritative source.
CMake Tools 1.24 changes that workflow for preset-backed entries. When a developer edits one of those values through the cache UI and saves it, the extension can write a user-preset override into CMakeUserPresets.json. The shared CMakePresets.json stays unchanged, while the local override inherits from it.
That separation is useful when testing low-level behavior such as pointers and memory addresses under different compiler flags or build options. A developer can change a local configuration without turning a personal experiment into a team-wide preset modification.
The extension can maintain supported source lists
When developers create or delete source files in VS Code Explorer, CMake Tools can now update their entries in supported CMakeLists.txt arrangements. The behavior is controlled by the cmake.modifyLists.* settings and follows the user’s confirmation configuration.
Microsoft is careful not to describe this as a general-purpose CMake script rewriter. Generated build scripts, complex variable logic and unusual target structures still need human review. But for conventional targets, reducing the chance that a new .cpp file exists on disk but never enters the build graph removes a common source of confusion.
That becomes particularly useful as projects add practical features such as file input and output, where new implementation files, test fixtures and helper targets can quickly expand the source tree.
The 1.24 branch also expands the build-system surface
The project’s official CMake Tools changelog lists additional 1.24 work across the extension, including FASTBuild generator support with newer CMake versions, a pre-configure task hook, multi-root exclusion improvements, and API events that allow dependent extensions to react after configure attempts.
Taken together, these changes show where C++ tooling is heading: the editor is becoming less of a text window wrapped around external build tools and more of an orchestration layer that understands tests, targets, presets, configuration state and source-file relationships.
What developers should still verify
Automation around build metadata can save time, but it also increases the importance of reviewing generated changes. Teams should still inspect modifications to CMakeLists.txt, confirm which target a test builds, and keep shared project presets distinct from machine-specific user presets.
For C++ developers, CMake Tools 1.24 is not a new compiler or language standard. Its value is smaller and more operational: fewer unnecessary rebuilds, fewer preset conflicts, less manual source-list maintenance and a shorter path from editing a test to running it.
BitcoinVersus.Tech
Advertisement
Editor’s Note
This report focuses on the CMake Tools 1.24 developer-workflow changes rather than treating the extension as a replacement for reviewing CMake configuration and generated build behavior. The featured cover is an original editorial illustration and is not duplicated in the article body.
We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support our research initiatives, please donate here: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb
BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.
Leave a comment