Better handling of build preset targets #295

arntanguy · 2025-02-05T13:29:35Z

In the current implementation, the targets field of CMakePresets.json is ignored. This leads to inconsistencies between what cmake-tools.nvim does and displays and what the user expects to happen.

Here is an example buildPresets showcasing the 4 possible cases:

One target specified as a string
One target specified as an array with a single string
Several targets specified
No target specified

  "buildPresets": [
    {
      "name": "build-one-string",
      "configurePreset": "release",
      "configuration": "Release",
      "targets": "target1"
    },
    {
      "name": "build-one-array",
      "configurePreset": "release",
      "configuration": "Release",
      "targets": ["target1"]
    },
    {
      "name": "build-two",
      "configurePreset": "release",
      "configuration": "Release",
      "targets": ["target1", "target2"]
    }
    {
      "name": "build-notarget",
      "configurePreset": "release",
      "configuration": "Release",
    }
  ]

One expects that :

when calling :CMakeSelectBuildPreset the internal build_target to be updated. This ensures that calling get_build_target() returns the target specified in the preset (for lualine for instance).
when calling :CMakeBuild the command executed to be cmake --preset <preset_name> without additional --target arguments

The current behaviour priour to this PR is to:

Disregard the targets field of the CMakePresets.json
Run cmake --preset <preset_name> --target <whatever the previously specified target was>

For a more concrete use-case, consider embeded development with a build-preset preset with a build-target target and and a flash-preset preset with a flash-target target that flashes the program onto the device.

  "buildPresets": [
    {
      "name": "build-preset",
      "configurePreset": "release",
      "configuration": "Release",
      "targets": "build-target"
    },
    {
      "name": "flash-preset",
      "configurePreset": "release",
      "configuration": "Release",
      "targets": ["flash-target"]
    },

Currently, the following would happen:

:CMakeSelectBuildPreset build-preset
- the build-preset is indeed selected
- build_target: none => we expected build-target instead
:CMakeBuild will prompt for a target, we select build-target, and cmake --preset build-preset --target build-target is run
:CMakeSelectBuildPreset flash-preset
- the flash-preset is indeed selected
- build_target: build-target => we expected flash-target
- :CMakeBuild runs cmake --preset flash-preset --target build-target => we expected to run the flash-target

You get the gist. This PR fixes this behaviour in the following way:

When a new build preset is selected, the build_target is changed to what's specified in that preset with one caveat: multiple targets targets: ["target1", "target2"]. Since this case is not handled anywhere else in the code, I simply put the build_target = nil
The user only gets asked for which target to select if none where defined in the selected preset
The build command is always cmake --preset <selected_preset> if at least one target is specified in the preset, otherwise it is cmake --preset <selected_preset> --target <user selected target>

It would probably be better to have a proper way of handle the multiple-targets case. However this seemed too big of a change, for little benefit for me to tackle right now.

lceWolf · 2025-02-22T22:44:11Z

lua/cmake-tools/init.lua

-  if opt.target == nil and config.build_target == nil then
+  local presets = Presets:parse(config.cwd)
+  local build_preset = presets:get_build_preset(config.build_preset)
+  if (not config.build_preset or config.build_preset and not build_preset.targets) and opt.target == nil and config.build_target == nil then


build_preset could be nil. You will run into an index into nill error on build_preset.targets in this case. Maybe check for if (not build_preset or not build_preset.targets) ... ?

lceWolf · 2025-02-22T22:49:03Z

lua/cmake-tools/init.lua

+  if not build_preset or build_preset and not build_preset.targets then
+    if opt.target ~= nil then
+      vim.list_extend(args, { "--target", opt.target })
+      vim.list_extend(args, fargs)
+    elseif config.build_target == "all" then
+      vim.list_extend(args, { "--target", "all" })
+      vim.list_extend(args, fargs)
+    else
+      vim.list_extend(args, { "--target", config.build_target })
+      vim.list_extend(args, fargs)
+    end


If you want the build_preset.targets to take precedence, you can check for if build_preset and build_presets.targets first and have elseif opt.target second, right?

lceWolf · 2025-02-22T22:50:44Z

lua/cmake-tools/init.lua

  end

-  if config.build_type ~= nil then
-    vim.list_extend(args, { "--config", config.build_type })
+  if not build_preset then


why this additional if?

lceWolf · 2025-02-22T22:57:22Z

lua/cmake-tools/init.lua

+            end
+          end
+        else -- build preset does not have a target, ask
+          config.build_target = nil


if the build_preset does not have a target, the currently selected one should be kept.

lceWolf · 2025-02-22T23:00:38Z

lua/cmake-tools/init.lua

+            else
+              -- XXX: Array targets are not supported in other code paths
+              -- As a workaround, unset the current build_target if any (it is not used when using build presets)
+              config.build_target = nil


as we do not have a handling for multiple build targets currently, you could either keep the currently selected one (if it is part of the array) or always select the first one from the list. The user can still change the target, if needed.
Resetting the selected target is not desirable, I think

I think a refactoring to support multiple targets might be helpful. But this is beyond the scope of this MR for sure.

lceWolf · 2025-02-22T23:05:15Z

I appreciate the PR and think it is a step in the right direction for sure. Very nice write-up of the motivation and your approach!
Thanks for taking care of that topic.

fix: Handle build preset targets

dc0c7cf

lceWolf reviewed Feb 22, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Better handling of build preset targets #295

Better handling of build preset targets #295

Uh oh!

arntanguy commented Feb 5, 2025

Uh oh!

lceWolf Feb 22, 2025

Uh oh!

lceWolf Feb 22, 2025

Uh oh!

lceWolf Feb 22, 2025

Uh oh!

lceWolf Feb 22, 2025

Uh oh!

lceWolf Feb 22, 2025

Uh oh!

lceWolf commented Feb 22, 2025

Uh oh!

Uh oh!

Better handling of build preset targets #295

Are you sure you want to change the base?

Better handling of build preset targets #295

Uh oh!

Conversation

arntanguy commented Feb 5, 2025

Uh oh!

lceWolf Feb 22, 2025

Choose a reason for hiding this comment

Uh oh!

lceWolf Feb 22, 2025

Choose a reason for hiding this comment

Uh oh!

lceWolf Feb 22, 2025

Choose a reason for hiding this comment

Uh oh!

lceWolf Feb 22, 2025

Choose a reason for hiding this comment

Uh oh!

lceWolf Feb 22, 2025

Choose a reason for hiding this comment

Uh oh!

lceWolf commented Feb 22, 2025

Uh oh!

Uh oh!