Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
neundorf opened this issue Feb 23, 2025 · 2 comments
Open
Labels
enhancement an enhancement to the product that is either not present or an improvement to an existing feature Feature: presets
Milestone

Comments

@neundorf
Copy link

Brief Issue Summary

We discussed this over here, now I created an issue for it as requested:
#4264 (comment)

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

@neundorf
Copy link
Author

Is there anything I can do to make this happen ?

@Yingzi1234 Yingzi1234 added enhancement an enhancement to the product that is either not present or an improvement to an existing feature and removed triage labels Feb 27, 2025
@gcampbell-msft gcampbell-msft moved this from Blocked to Pending Prioritization in CMake Tools Feb 28, 2025
@gcampbell-msft gcampbell-msft added this to the Backlog milestone Feb 28, 2025
@gcampbell-msft
Copy link
Collaborator

@neundorf Thanks for creating the issue, and thanks for the idea! We have triaged this, and we will do our best to prioritize accordingly, however, as you can imagine with the number of items posted on this repo, there is a lot to juggle.

Typically, we also prioritize based on the number of upvotes on a feature. We are also open to OSS contributions. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement an enhancement to the product that is either not present or an improvement to an existing feature Feature: presets
Projects
Status: Pending Prioritization
Development

No branches or pull requests

3 participants