Loading an existing cmake build directory

[neundorf]

VS Code uses CMakePresets.json (where you can configure e.g. the generators and the build directories), it also supports cmake settings in the settings.json (where you can also configure the generator and the build directory), and both of that limits users who would like to use the full flexibility of cmake, e.g. creating multiple slightly different build directories for one source tree (with different build types, different options, etc.).

I suggest to add the feature to "load" an existing cmake build directory. AFAICS it contains all information that VS Code needs via the file API. From the CMakeCache.txt, vs code could parse CMAKE_COMMAND, which gives the path to the cmake that has been used to create that build dir. Then vs code can write a file API query file, rerun cmake, and read everything it needs to know from the response files: the build- and source-directories in codemodel.json, the generator in index.json, the compiler in toolchains.json.

Then any user who knows how to use cmake can create the build directories as he is used to from cmake (build types, different compilers etc.), and simply load them, without having to edit additional text files, which may have to go into VCS.

[gcampbell-msft]

@neundorf I'd love to understand more about the "limit users" statement. You mention that it supports both the CMakePresets.json and the VS Code settings.json, how does this limit using the full flexibility of cmake?

We do have the ability to load existing settings I believe, if you use the setting cmake.skipConfigureIfCachePresent

[neundorf]

I was just starting...;-)

I might also want to try gcc 13 and gcc 14, or different versions of any compiler, or maybe once in an Ubuntu 24.04 podman container and once in an SUSE Leap container.
With cmake, I simply either set CC and CXX, or run cmake in the appropriate cmd.exe coming with Visual Studio, in the build directory I want, and that's all I have to do. I can create any number of different build variants, each with its own build dir.

Also, I know how to handle cmake variables vs. cmake cache variables (which is complicated enough), and I don't have to worry whether those will be overridden by those set in the presets file (not sure whether that's cmake feature or a Visual Studio (not code) feature). Because they are overridden by those in the CMakePresets.json, in one case I had to duplicate ALL configure presets, once with ENABLE_FOO=TRUE, and once with ENABLE_FOO=FALSE, because changing that option() in the cmake cache didn't work anymore, it was ignored, so it doubled the number of presets, for one tiny option.

[neundorf]

And I'm sure all the information you need is easy to get via the cmake file API (I implemented that for Kate).

[gcampbell-msft]

@neundorf Haha no worries, I understand, it sounds like you're possibly running into the issue you linked.

You're essentially saying that while yes, theoretically the cmake.skipConfigureIfCachePresent setting would work for you, this would still require the massive amount of presets, since it's still based on a preset pointing at a certain buildDir.

However, what you're asking for, is essentially a workaround where we could provide the ability to directly read all the relevant information from a cache. Essentially, you could possibly even create all of your presets from a pre-existing cache, saving the user the need to create all of the presets you need, but instead being able to load from a cache and have the CMake Tools extension generate your settings (presets file) for you.
It would essentially be another way to create a presets. For example, using the quick start flow in the extension, an option could be to load from a cache?

Am I understanding all of that correctly?

If so, I'd love if you converted this discussion post into an issue (which will be labeled a feature request) and make sure that when you convert it you explicitly write out the scenario you have in mind and what you would hope it to look like (mostly already done in this issue, but just make sure it's clear so that if we don't get to it for awhile, but come back to it, it's easy to understand).

Thanks!

[neundorf]

Interesting idea. I could write some script which uses the information from a build tree to wite/extend a CMakeUserPresets.json file...

I'm not sure... I don't know how VS Code cmake tools handle this internally and what information they actually need/use.

You write "read all .. information from a cache". Not exactly. I'd suggest to read CMAKE_COMMAND from CMakeCache.txt to know which cmake exactly was used to create it, then create the file API query file, then run the cmake on the build tree, it will write the response files, and then read everything that VS Code / CMake Tools need from those files:

• source dir
• configuration/build type
• generator
• toolchain (for error/warning parsing maybe ?)
• available targets and their files
• etc.

I don't know any code from VS Code/CMake tools... I could image that creating a CMakePresets.json is not really necessary, but that the information which is used internally can be created directly.

[gcampbell-msft]

@neundorf Ah, I understand, just parse enough to be able to run the configure step correctly ourselves, which will then create everything we need.

Could you create an issue for this so that we can better track it? We track our priorities in the Issues page rather than the discussions page. Thanks!