Handling of CMake _buildPresets_

[ktetzlaff]

Before merging #4 (s. issue #3 for details) cmake-integration.el used buildPresets to

1. select the binaryDir
2. select the configuration (and all other buildPreset attributes)

After the merge, the way multi-config targets are handled has changed. In 2. the buildPreset configuration is now ignored (it gets overruled with the config selected by the user via the completion interface). That could easily be fixed by updating cmake-integration-get-cmake-targets-from-codemodel-json-file to add an additional config-less target for each target name. I.e.:

• all
• all/Debug
• all/Release
• all/RelWithDebInfo
• foo
• foo/Debug
• foo/Release
• foo/RelWithDebInfo
• ...

These additional targets would then automatically build the

• buildPreset configuration for preset builds
• configuration defined by CMAKE_DEFAULT_BUILD_TYPE for non-preset builds

And I would probably also add a new command in addition to `cmake-integration-save-and-compile` where the completion list just offers the configured _buildPresets_. E.g. rename `cmake-integration-save-and-compile` to `cmake-integration-build-target` and add `cmake-integration-build-preset`.

What do you think?

[darcamo]

Just a clarification, the preset the the user currently chooses is the "configure preset". Then, when building, it's assumed that a "build preset" with the same name exists.

One possibility is to check in cmake-integration-save-and-compile if there are any "build presets" whose configure preset is the one currently in use. We have 3 possibilities:

• There are at least one build preset referencing the currently used configure preset
  • In that case, build the list of candidates from the preset name and the target name
• There are no build presets
  • The behavior should be like what we have now

We can also not use build presets until we can think about a good way to do it. Right now assuming that there exists a build preset with the same name of the configure preset when configure presets are used is an unnecessary limitation.

[ktetzlaff]

We can also not use build presets until we can think about a good way to do it. Right now assuming that there exists a build preset with the same name of the configure preset when configure presets are used is an unnecessary limitation.

As I suggested earlier, I would completely separate normal builds from preset builds by using two separate commands.

The last configure preset could then still be used for normal builds as an easier way to select the binaryDir (instead of manually setting cmake-integration-build-dir) ¹.

But buildPresets would be handled independent from the configurePresets (maybe, when selecting a buildPreset which doesn't have a binaryDir, it could get generated automatically by first calling cmake-integration--cmake-configure-with-preset with the linked configurePreset).

Footnotes

1. For projects which don't use a CMakePresets.json It might also be worth to add a additional, separate command which allows to select the current binaryDir (e.g. by searching the file system for sub-directories of <prjroot> which contain a CMakeCache.txt file). ↩

[darcamo]

Build presets can also set things like the number of parallel jobs (for make generator), environments variables, a target name (so that you do not need to specify it) and a few other things. But the most important information, including binaryDir, is in the configure preset.

From the documentation for build presets, they either need to have a configurePreset field specifying the configure preset for them (from which they will take the binaryDir value, of they need to inherit from a different preset that has a configurePreset field.

configurePreset

An optional string specifying the name of a configure preset to associate with this build preset. If configurePreset is not specified, it must be inherited from the inherits preset (unless this preset is hidden). The build directory is inferred from the configure preset, so the build will take place in the same binaryDir that the configuration did.

We can use configure presets without using any build presets, bit it seems that if we want to use build presets we also need to use configure presets, since each build preset needs to have an associated configure preset somehow (directly of by inheriting from another preset). I agree that the user should still be able to choose them separately (instead of assuming you have both kinds of presets and they have the same name), as well as being able to use only configure presets.