vscode-cmake-tools: CmakePresets: Selecting of build targets seems not to be supported or not working

Hey folks, CMake co-maintainer here. I’m seeing this issue really hurting adoption of CMake presets among the user community. Anyone who works on a non-trivial sized project is going to be hitting this problem.

I was trying out the suggested workaround of using Shift+F7 to build a specific target, but I found that when I did that, I didn’t get a list of defined targets to pick from and instead had to manually type in a target name. No developer is going to be happy doing that every time they want to do a build in their day-to-day workflow. The combinatorial explosion that would result from having to create a build preset for every target and every configuration is also not practical and not friendly to users. There’s some further context in the upstream CMake issue: https://gitlab.kitware.com/cmake/cmake/-/issues/22538

Is it possible to consider @hwmaier 's suggestion and re-enable the “CMake: Set Build Target” code, at least for now while a deeper solution is being worked on? That would at least give users a considerably better experience with presets in the short term for what seems like pretty low cost (given the code is already there and was used previously before presets came along). Even if it was hidden behind some kind of experimental or “use at your own risk” flag, that would be considerably better than what we have now.

And to re-iterate, this is really hurting adoption.

We got excactly the same usecase as @hwmaier.

Multiple platforms and toolchains and big projects with many targets. Users want to build only a single targets, they currently develop for faster test build or debug.

PS: the proposed target selection statusbar button should also be used for the play and debug button! (similar to this request https://github.com/microsoft/vscode-cmake-tools/issues/1941)

@andreeis Thank you for explaining.

I think moving from the Kit/Variant method to the official CMake Preset method is the right move and it greatly improves transitioning between IDE and command line use.

But I still think there is a use case for being able to select a target in addition or alternatively to selecting a build preset in the IDE (as the CMake command line supports this as well).

• Having to add targets to CMakePresets.json doubles up project maintenance, Targets have to be defined in CMakeLists.txt and then again in CMakePresets.json.
• Build presets are tied to a configuration preset. So for projects with many different configurations (like embedded systems targeting a larger number of different hardware architectures), we would have to add all combinations of targets vs configurations. Very hard to maintain.
• The CMake command line allows specifying --target in conjunction with --preset

From my understanding of CMake’s preset, you either use a Configuration Preset or a Build Preset on the command line. Never both. A target can be added optionally.

So I would expect that the CMake Tools would reflect that somehow and either allow you choose a Configuration Preset OR a Build Preset. But the selection of a Build Preset should be optional and target selection should be possible too (unless a targets field is specified in the Build Preset).

The Target selection then also could be used automatically as the debug target.

There are others finding the loss of target selection a stop backwards: refer to https://devblogs.microsoft.com/cppblog/cmake-presets-integration-in-visual-studio-and-visual-studio-code/#comment-1693

I’m not sure how this alone will help the customer in the upstream CMake issue.

@esweet431 I linked that issue mostly for context, since it highlights how needing to define build presets for whatever you want to build quickly gets away from you and requires defining many build presets to do even basic things. This issue here is effectively another layer on top of that combinatorial explosion - not only do you need at least one build preset per configure preset, you also need one build preset per target you want to build. This last part is particularly painful, because projects often have many targets. Being able to have VS Code automatically provide the list of targets as it did before presets came along removes this last layer of combinatorial expansion of presets. For many, it will also mean they don’t need to define any build presets at all.

And thanks folks for moving forward with this for 1.9, it’s much appreciated.

Sure, I fully support adding this back.

That said, I’m not sure how this alone will help the customer in the upstream CMake issue. As of CMake 3.21, that customer will still need to maintain an explosion of build presets due to the enforced mapping between configure presets and build presets. The customer in the upstream issue relies on build presets to set configuration, and they will still need all of those build presets until configurePreset becomes either an array or regex.

@craigscott-crascit thanks for chiming in. I am in agreement that the flow currently sucks. We used to have a good solution for combinatorial explosion with Variants, but that feature is unavailable with presets. It would be nice if something like that could be engineered into presets somehow because I think there is explosion with configure presets as well (not just build presets). How to select a given combination on the CLI would need to be determined though.

If @esweet431 is ok with it, we can add support for persisting a target back for the presets case.

I totally agree with @craigscott-crascit sentiment here. It has been a few month since my original suggestion that a mechanism needs to be available to switch targets. And this mechanism needs to be simple and convenient. Basically as it used to be, before presets came along. Before presets we switched targets by a simple click on the status bar. Shift-F7 is no practical work around as the selection is not persistent, next time you hit F7 all targets are built again, Also no visual indication is given in the status bar which target you are working on.

We have a similar use case and would like to see the option of setting a single build target, again.

Our application has multiple libraries, and a few executables that link with the libraries. If working on one library, I am only interesting in compiling that, so I would select that as my build target and just press “F7” while working to run a compile.

The way we work around it now, is to ask people to create a CMakeUserPresets.json and add a “BuildPreset” entry for the target they are working on.