CmakePresets: Selecting of build targets seems not to be supported or not working

[hwmaier]

Brief Issue Summary

The CMake Tools when using kits and variants allow easy selection of the current build target using either a command or a selector in the toolbar next to the Build icon. It is very easy to switch between different compilation targets in multi-target cmake files or alternatively selecting of [all].

Example:

The new CMake Tools "CmakePresets" feature does unfortunately not offer changing the target. Neither is there a similar target icon/selector in the toolbar nor seems there to be a way to change the target otherwise. The Cmake: Set Build Target command is not even listed on my machine nor does running CMake: Set Debug Target work either, but at least the command is listed.

Platform and Versions

• Operating System: Windows 10
• CMake Version: 3.20.2
• VSCode Version: 1.56.1
• CMake Tools Extension Version: 1.7.3
• Compiler/Toolchain: not relevant

[andreeis]

Setting a build target via a command or a UI element is disabled when presets are used. This is by design for now. I will consult with the team about the possibility of supporting something like this in the future and get back to you.

In the meantime, you can use the keyword "targets" within a build preset, as described in the official presets CMake documentation: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html.

Regarding the "CMake: Set Debug Target" command not working, I've seen this happening when using presets with Ninja generator and without defining a CMAKE_BUILD_TYPE. Add it as a preset cache variable (with value "Debug" for example) and let us know if you are able to select a debug target.

[andreeis]

We will definitely improve in time the UI experience of creating a new preset (which can allow build targets selection which doesn't now) or maybe even extend that UI experience for edit mode (besides the creation mode). Would that work for you instead of what you propose?
But since what you are asking is slightly different than what I imagine above, I will let @esweet431 comment more about why this is by design or if we could offer an UI scenario for this in the future.

[hwmaier]

Regarding the "CMake: Set Debug Target" command not working, I've seen this happening when using presets with Ninja generator and without defining a CMAKE_BUILD_TYPE. Add it as a preset cache variable (with value "Debug" for example) and let us know if you are able to select a debug target.

Yes, I can confirm that Ninja is used in my use case as generator and CMAKE_BUILD_TYPE was not set. Once set to "Debug" I can select a debug target,

[hwmaier]

@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

[esweet431]

Hi @hwmaier,

Running "CMake: Build Target" allows you to build a single target with the instructions encoded in the active Build Preset. This is the equivalent of passing --target and --preset from the command line. Does this unblock your scenario, or do you need a way to persist a single active build target? If you always want to build the same target, then I recommend creating a Build Preset that specifies the target with the 'targets' option. If you frequently toggle between build targets, then hopefully the "CMake: Build Target" command will work for your needs.

Invoking Configure Presets and Build Presets from the command line are two discrete steps, but they can be (and often are) paired together. The Configure Preset encodes instructions that are specific to the configure step, while the Build Preset encodes instructions that are specific to the build step. That's why cmake-tools surfaces both your active Configure Preset and your active Build Preset. Let me know if you have any more questions about this design.

[hwmaier]

Hello @esweet431,

Thank you so much for looking into this use case.

Running "CMake: Build Target" allows you to build a single target with the instructions encoded in the active Build Preset. This is the equivalent of passing --target and --preset from the command line. Does this unblock your scenario, or do you need a way to persist a single active build target? If you always want to build the same target, then I recommend creating a Build Preset that specifies the target with the 'targets' option. If you frequently toggle between build targets, then hopefully the "CMake: Build Target" command will work for your needs.

That's exactly my point. Most of our projects don't have a single target but multiple targets and we switch between them frequently. In addition we have typically between 4 to 8 configurations (different processor architectures). So embedding the target into the buildPresets is not feasible as we would have to create too many buildPresets entries to cover all combinations of configurations and targets.

We currently are using two methods.
Method A is not using build presets, only configuration presets. On the command line we configure like this:

cmake --preset stm32f4-disco    

and then build using this :

cmake --build build\stm32f4-disco --target uhttpd

Method B is a bit more involved, we add for each configuration preset a build preset with the same name and keep the targets field empty.

    "configurePresets": [
        ...
        {
            "name": "stm32f4-disco",
            "description": "STM32F4-DISCO board",
            "inherits": "arm-embedded",
            "cacheVariables": {
               ...
            }
        }
    ],
    ...
    "buildPresets": [
        {
            "name": "stm32f4-disco",
            "configurePreset": "stm32f4-disco"
        }
    ]

 cmake --preset stm32f4-disco    

and then build using this :

cmake --build --preset stm32f4-disco --target uhttpd

In both scenarios we can specify the build target using the --target command line option rather than building all targets.

So it would be nice if VSCode supports both or at least one of above approaches. One where only configuration presets are used and build presets are not used and the target can be optionally selected from a menu. The other where both configuration and build presets are used but no targets field is specified in the preset and again the target can be selected from a drop-down menu

All which would be required is to re-introduce the target selection drop-down menu which the former kits/variants model already has.

Here is a little mock-up how this could look like:

[esweet431]

Thanks for the feedback! We do support this scenario:

One where only configuration presets are used and build presets are not used and the target can be optionally selected from a menu.

To achieve this:

1. Select your active Configure Preset (CMake: Select Configure Preset)
2. Select the "Default" Build Preset (CMake: Select Build Preset). The default Build Preset is implicit (never written to CMakePresets.json) and a full build is equivalent to running cmake --build build\stm32f4-disco from the command line.
3. Build using the "CMake: Build Target" command. This command will prompt you with a list of targets to build. The selected target will be the only target that VS Code builds. This is the same as adding --target <target> to the command above, ie cmake --build build\stm32f4-disco --target <target>

Since you aren't passing any additional command line arguments to --build, I agree that option 1 is the cleanest approach. You shouldn't need to maintain any Build Presets at all. Please let me know if this approach works for your team.

[hwmaier]

@esweet431

3. Build using the "CMake: Build Target" command. This command will prompt you with a list of targets to build. The selected target will be the only target that VS Code builds. This is the same as adding --target <target> to the command above, ie cmake --build build\stm32f4-disco --target <target>

Confirmed, using the command "CMake: Build Target" (or Shift F7) does allow selection of the target from the menu for the next build. Somehow I missed that. Thank you for pointing it out.

So when I compare the "CMake Preset" build workflow to the former "CMake Kit/Variant" method, the former has theses advantages:

• Default target selection is persistent during the editor session.
• The selected target is passed down to CMake when running the ${command:cmake.tasksBuildCommand} command from a task
• The selected target is available in the ${command:cmake.buildTargetName} variable (I also tried "${command:cmake.tasksBuildCommand} --target ${command:cmake.buildTargetName}" but it passes always all as target.)
• The selected target is shown in the toolbar and can be changed from the toolbar

Are there any plans to match the functionality and make the target selection persistent for the session and also to be able to pass it with the ${command:cmake.tasksBuildCommand} command (see https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md)?

That would be a huge productivity boost as the command:cmake.tasksBuildCommand can be used in tasks and bound to a hotkey (like Ctrl-Shift-B).

Addendum: I just went through the doc on https://github.com/microsoft/vscode-cmake-tools/blob/develop/docs/cmake-presets.md#cmake-build again. There is says there would be a command "CMake: Set Build Target.". For some reason this command is not available on my system. What would prevent this from be available?

[hwmaier]

Addendum: I just went through the doc on https://github.com/microsoft/vscode-cmake-tools/blob/develop/docs/cmake-presets.md#cmake-build again. There is says there would be a command "CMake: Set Build Target.". For some reason this command is not available on my system. What would prevent this from be available?

I just had a look at the source code of vscode-cmake-tools, according to file package.json , the command "CMake: Set Build Target." is not available when using presets, see when clause:

      {
        "command": "cmake.setDefaultTarget",
        "title": "%cmake-tools.command.cmake.setDefaultTarget.title%",
        "when": "cmake:enableFullFeatureSet && !useCMakePresets",
        "category": "CMake"
      },

This is in contrary to the documentation (https://github.com/microsoft/vscode-cmake-tools/blob/develop/docs/cmake-presets.md#cmake-build) which states "Run CMake: Build Target from the command palette to build a single target. You can switch the active build target by running CMake: Set Build Target."

[esweet431]

You're right. I have a PR out now to update the documentation to match the current implementation (#1893).

We can keep this issue open to track the 4 feature gaps you identified above that surface when "CMake: Set Build Target" is not supported.

• Default target selection is persistent during the editor session.
• The selected target is passed down to CMake when running the ${command:cmake.tasksBuildCommand} command from a task
• The selected target is available in the ${command:cmake.buildTargetName} variable (I also tried "${command:cmake.tasksBuildCommand} --target ${command:cmake.buildTargetName}" but it passes always all as target.)
• The selected target is shown in the toolbar and can be changed from the toolbar

[hwmaier]

You're right. I have a PR out now to update the documentation to match the current implementation (#1893).

I wished instead of updating the documentatiuon the PR would unhide the already existing "CMake: Set Build Target" feature. I patched my local extension code and managed to have "CMake: Set Build Target" available from the menu and it works. So all the code is already there, its simply "hidden".

But I appreciate that you keep the feature request open for the future and I am happy to assist with testing and discussions. Thank you so much for providing the enhanced CMake plugin and all the documentation and blog posts.