microsoft / microsoft/vscode-cmake-tools
Remove kits/variants
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1.7k
- Forks
- 546
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 32
Description
Brief Issue Summary
Here is a bold ask, and I am not sure it makes sense, but I thought it would not hurt to bring it up.
Both https://code.visualstudio.com/docs/cpp/cmake-linux and https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-presets.md recommends using CMake Presets, the official way to share CMake configs in various ways.
VS Code seems to include a Kits and Variants option, but it is not recommended.
I have never tried Kits/Variants, so it is possible they bring something to the table that CMake Presets does not, but if they do not do that, would it not simplify a lot by removing support for Kits/Variants altogether?
The rationale behind this is to make it easier to get started with VS Code and the CMake Tools extension. For example the CMake Kits and CMake Variants mentions nothing about that CMake Presets is preferred, whilst the other pages links above does.
I think you can close this immediately if it makes no sense, but I am coming from a point of having read all docs and felt this would simplify quite a bit just plainly removing this concept if it adds no extra value on top of CMake Presets.
Another benefit if that CMake Presets works better with teams that prefer to e.g. use other tools such as Vim or Emacs.
CMake Tools Diagnostics
n/a
Debug Log
n/a
Additional Information
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading docs/kits.md and docs/variants.md, then compare their documented capabilities with the linked CMake Presets guidance. Trace where Kits and Variants are referenced in the project before proposing a scope. Done means the project has a clear decision about whether they provide unique value and, if not, their support and documentation references are removed consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake
- Domain
- build-system, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100