cmakeclionvcpkgcmake-presets

CLion Project using CMakePresets.json not able to find vcpkg


I have a CLion Project setup using CMakePresets.json, and I'd like to us vcpkg with it. I specify where the vcpkg toolchain is, but CLion does not seem to take this into consideration and both the vcpkg entry is greyed out, and I get CMake Build errors about not being able to find whatever librarys I have installed via vcpkg. CLion project using CMakePresets.json, CLion is not able to locate vcpkg despite its location being provided CMake Errors on not finding the 'fmt' library installed via vcpkg

However, if I make a new CLion project and do not use CMakePresets.json, CLion is able to locate vcpkg just fine and I do not get any errors about CMake not being able to find libraries. Sample CLion project, not using CMakePresets.json is able to find vcpkg

Is there something I am missing for my CLion Profiles in this project to not be able to detect the vcpkg installation location?

Below is my full CMakePresets.json file used by the CLion project:

{
  "version": 6,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 29,
    "patch": 0
  },
  "include": [],
  "configurePresets": [
    {
      "name": "base",
      "displayName": "Base Config",
      "description": "Base configuration using Ninja generator",
      "generator": "Ninja",
      "hidden": true,
      "toolchainFile": "D:\\vcpkg\\scripts\\buildsystems\\vcpkg.cmake",
      "cacheVariables": {
        "CMAKE_CXX_STANDARD": "23"
      },
      "warnings": {
        "dev": true,
        "uninitialized": true
      },
      "errors": {
        "dev": true,
        "deprecated": true
      }
    },
    {
      "name": "debug",
      "inherits": "base",
      "displayName": "Debug",
      "description": "Debug configuration using Ninja generator",
      "binaryDir": "${sourceDir}/build/debug",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug",
        "CMAKE_CXX_FLAGS_DEBUG": "-O1"
      }
    },
    {
      "name": "release",
      "inherits": "base",
      "displayName": "Release",
      "description": "Release configuration using Ninja generator",
      "binaryDir": "${sourceDir}/build/release",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Release",
        "CMAKE_CXX_FLAGS_RELEASE": "-O3"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "debug",
      "displayName": "Debug",
      "configurePreset": "debug",
      "verbose": true
    },
    {
      "name": "release",
      "displayName": "Release",
      "configurePreset": "release",
      "verbose": true
    }
  ],
  "workflowPresets": [],
  "testPresets": [],
  "packagePresets": [],
  "vendor": {}
}

Solution

  • I've gotten it semi-working now (I can use vcpkg libraries, but the integrated vcpkg does not work for CMakePresets.json projects), here's a couple things that I've noticed:

    1. Even though the Configuration/Build Presets show up under CLion Profiles, they are not CLion Profiles. So they will not appear as an option to associate CLions integrated vcpkg with, so it'll always appear grey'd out.

    2. When installing libraries using CLions integrated vcpkg, if you are using CMakePresets, you must install the correct triplet. You can not use the "let vcpkg decide" option. It appears that the integrated vcpkg can figure out which triplet to use if you are using a CLion Profile, but if you aren't using a CLion Profile then it will choose whatever the default triplet is for your system. (In my case, I did not have VS installed so the x64/x86 Windows triplets would not work, which was what were getting downloaded in the project using CMakePresets. In the sample project using CLion Profiles, the integrated vcpkg correctly figured that I needed the x64/x86 MinGW Dynamic libraries).

    3. I ended up installing vcpkg on my machine myself, instead of letting CLion install it. This shouldn't matter, as it appears the CLion integrated vcpkg just pulls vcpkg from github and runs the bootstrapper, but maybe it does something else not immediately obvious. Installing vcpkg myself seems to have gotten everything working/recognizable as far as running cmake goes.