microsoft / microsoft/vscode-cmake-tools

Create configure- and build-presets on-the-fly from an existing build tree

Open
#4,293 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement Feature: presets
Dominant language
TypeScript
Stars
1.7k
Forks
546
Avg merge
2d 16h
Merged PRs (30d)
32

Description

Brief Issue Summary

We discussed this over here, now I created an issue for it as requested:
https://github.com/microsoft/vscode-cmake-tools/discussions/4264#discussioncomment-12095234

This is about making it easier to use/"import" an existing cmake build tree without forcing the user to manually create a CMakeUserPresets.cmake.

I often create multiple build trees for one source tree: one for gcc 11, one for gcc 14, one for clang19, one with some project-specific options enabled, one for disabled, one with Qt5, one with Qt6, one under Ubuntu 24:04, one with AlmaLinux 9, one for each configuration, etc.

All I have to do for this is run cmake with the CC and CXX environment variables set respectively, and set some options via cmake-gui. Having to manually add an entry to CMakeUserPresets.json is tedious, and all the information I have to enter there can be easily retrieved via the cmake file API.

Actually I implemented this here as an option for cmake, but it hasn't been accepted yet: https://gitlab.kitware.com/neundorf/cmake/-/commit/f6e4e8a01e62ea0d52da9a2cb8f7d6d0b3f563bd

To my understanding, it should be easy for CMakeTools to create the information for a user preset on the fly when being pointed to a cmake build tree, i.e. when doing "Open folder" on a directory where a CMakeCache.txt exists.
If it exists, CMakeTools could parse the CMAKE_COMMAND entry from it (which is according to Brad King basically guaranteed to exist), then check whether a query file for vscode already exists, if not add one, and then run the cmake executables it has found in CMakeCache.txt on it.

Then, for getting all the information which would be necessary for CMakeUserPresets.cmake, all CMake Tools would have to do is:

  • create one configurePreset,
    • find the source directory via the file API in cmakeFiles.json paths::source
    • the "binaryDir" - CMakeTools knows which directory it is opening right now
    • has a "name" - CMakeTools can generate one, e.g. from the path of the build tree
    • maybe (not sure) the "generator" - can be read from file API in index.json, cmake::generator::name
  • create one buildPreset for each configuration, i.e. one for single-config generators, and one for each type for multi-config generators
    • from cache.json, read CMAKE_CONFIGURATION_TYPES in the file API for multiconfig generators, and CMAKE_BUILD_TYPE for single config generators
    • for each of these types
      • add a "name" - e.g. the name of he configurePreset with the buildtype appended
      • add the "configurePreset" it has just created
      • add the "buildType"

With this, I could add arbitrary build trees and just load them directly in VS Code, without having to manually write json syntax correctly.
... or without expecting my colleagues who just want to write C++ code to learn that there is a file called CMakeUserPresets.json andwhat json entries have to be added there so it shows up in VS Code.

CMake Tools Diagnostics

Debug Log

Additional Information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the existing-build-tree handling used when opening a directory containing CMakeCache.txt, then review the proposed inputs in cmakeFiles.json, index.json, and cache.json. Done means CMake Tools can derive configure and build presets on the fly, including configurations, without requiring a manually written CMakeUserPresets.json.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, typescript
Domain
build-system, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.