Can an extension run custom scripts before the build process?

[Logical_Elton (xXxslavchickxXx)]

The main problem for me is setting up the environment. I’m not a fan of changing the global state of the operating system, and I’d like to configure the environment for a specific terminal session via scripts, like MSVC does, but I didn’t find any documentation in this extension that mentions the possibility of installing custom scripts. Question: is such a possibility even available, or not? If not, then I’ll have to suffer and drag my CMakeUserPresets.json file from project to project, which sounds extremely discouraging.

[Meyshad (meyshad)]

For environment initialization, use a user-local CMake Tools kit with environmentSetupScript. That avoids copying CMakeUserPresets.json into each repository.

Run CMake: Edit User-Local CMake Kits from the Command Palette and add a kit such as:

[
  {
    "name": "My SDK environment",
    "environmentSetupScript": "C:/SDK/setup-env.bat",
    "keep": true
  }
]

The Windows script can set variables normally:

@echo off
set "SDK_ROOT=C:\SDK"
set "PATH=%SDK_ROOT%\bin;%PATH%"

On Linux, point the property at a shell script instead:

#!/usr/bin/env bash
export SDK_ROOT=/opt/sdk
export PATH="$SDK_ROOT/bin:$PATH"

Select that kit for the project. CMake Tools calls the batch file on Windows or sources the shell script in bash, then captures the resulting environment for configure, build, and test. keep: true prevents the custom kit from disappearing during kit rescans.

This hook is intended for environment setup. If the script generates files or performs an actual build step, put that work in a CMake custom command/target or a VS Code task instead. The supported format is documented under environmentSetupScript.

[Logical_Elton (xXxslavchickxXx)]

For environment initialization, use a user-local CMake Tools kit with environmentSetupScript. That avoids copying CMakeUserPresets.json into each repository.

Run CMake: Edit User-Local CMake Kits from the Command Palette and add a kit such as:

I’ve already tried to do this, but for some reason this option isn’t available in the command palette, and I can’t figure out why. The extension itself works; I can create custom configurations via the command palette, but for some reason I can’t edit custom kits.

[Logical_Elton (xXxslavchickxXx)]

Now I came across a post related to this issue #3550, and it says that it’s because presets and whales are mutually exclusive. But I don’t understand why presets don’t support custom scripts then?

[Logical_Elton (xXxslavchickxXx)]

Apparently, the current philosophy of CMake implies user presets of this kind:

{
  "version": 8,
  "configurePresets": [
    {
      "name": "default",
      "binaryDir": "${sourceDir}/out/build",
      "inherits": [
        "vcpkg-setup",
        "ninja-setup",
        "msvc-setup"
      ]
    },
    {
      "name": "ninja-setup",
      "inherits": "vcpkg",
      "generator": "Ninja",
      "cacheVariables": {
        "CMAKE_MAKE_PROGRAM": "C:/DevTools/ninja/ninja.exe"
      }
    },
    {
      "name": "vcpkg-setup",
      "environment": {
        "VCPKG_ROOT": "C:/DevTools/vcpkg"
      }
    },
    {
        "name": "msvc-setup",
        "environment": {
            "INCLUDE": "C:/Program Files (x86)/Windows Kits/10/include/10.0.26100.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.26100.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.26100.0/um;C:/DevTools/msvc/VC/Tools/MSVC/14.51.36231/include",
            "LIB": "C:/Program Files (x86)/Windows Kits/10/lib/10.0.26100.0/ucrt/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.26100.0/um/x64;C:/DevTools/msvc/VC/Tools/MSVC/14.51.36231/lib/x64",
            "PATH": "C:/Program Files (x86)/Windows Kits/10/bin/10.0.26100.0/x64;${penv:PATH}"
        },
        "cacheVariables": {
            "CMAKE_C_COMPILER": "C:/DevTools/msvc/VC/Tools/MSVC/14.51.36231/bin/Hostx64/x64/cl.exe",
            "CMAKE_CXX_COMPILER": "C:/DevTools/msvc/VC/Tools/MSVC/14.51.36231/bin/Hostx64/x64/cl.exe"
        }
    }
  ]
}

Instead of using a single script that can be preconfigured to set up the environment and be used in every project. In my opinion, launching user scripts could at least be provided via CMakeUserPresets.json, given that, by philosophy, these are user‑specific settings that another user should not see.

[Meyshad (meyshad)]

Thanks, that explains why the command was missing. My previous answer missed an important detail: CMake Tools uses either Presets mode or Kits mode for a folder. With cmake.useCMakePresets set to auto, the presence of CMakePresets.json enables Presets mode, and the kit commands are intentionally unavailable. Therefore, environmentSetupScript is only an option if you disable preset integration with "cmake.useCMakePresets": "never".

You are also right about the limitation. The CMake Presets schema supports an environment map, but it has no standard field for sourcing an arbitrary setup script. So there is currently no preset equivalent of environmentSetupScript.

You do not need to duplicate the entire configuration in every project, though. Since preset schema version 7, CMakeUserPresets.json can include a shared file using $penv{...}, and user preset files are allowed to include files from outside the project:

{
  "version": 8,
  "include": [
    "$penv{USERPROFILE}/.cmake/common-presets.json"
  ],
  "configurePresets": [
    {
      "name": "default",
      "inherits": "my-local-toolchain",
      "binaryDir": "${sourceDir}/out/build"
    }
  ]
}

The shared file can contain the hidden MSVC, Ninja, and vcpkg presets. Each project then only needs this small bridge file instead of another copy of all the paths.

If running one setup batch file is essential, another process-local option is to start a new VS Code instance from the initialized shell:

call C:\path\to\setup-env.bat
code -n .

VS Code and CMake Tools will inherit that environment without changing the global OS environment.

One additional note: cmake.preConfigureTask has been merged for the upcoming 1.24 release, but it runs the script as a separate VS Code task. It is useful for generating files before configuration, but environment variables set by that task cannot propagate to the later CMake process.

So your request for a preset-side equivalent of environmentSetupScript is still valid.