CMakePrests.json toolset requires the VS version instead of the toolset version

[barcharcraz]

I'm using the following CMakePresets.json file

{
    "version": 2,
    "configurePresets": [
        {
            "name": "base",
            "hidden": true,
            "generator": "Ninja",
            "binaryDir": "${sourceDir}/out/build/${presetName}",
            "cacheVariables": {
                "CMAKE_CXX_COMPILER": "cl.exe",
                "CMAKE_C_COMPILER": "cl.exe",
                "CMAKE_BUILD_TYPE": "Debug"
            },
            "toolset": {
                "value": "x64",
                "strategy": "external"
            }
        },
        {
            "name": "x86",
            "inherits": "base",
            "architecture": {
                "value": "x86"
            }
        },
        {
            "name": "x64",
            "inherits": "base",
            "architecture": {
                "value": "x64"
            }
        },
        {
            "name": "ARM",
            "inherits": "base",
            "architecture": {
                "value": "arm"
            }
        },
        {
            "name": "ARM64",
            "inherits": "base",
            "architecture": {
                "value": "arm64"
            }
        }
    ],
    "buildPresets": [
        {
            "name": "default",
            "configurePreset": "base",
            "verbose": true
        }
    ]
}

Whenever a new preset is selected cmake tools prints:

[preset] Configure preset x86: No toolset architecture specified for cl.exe, using x86 by default
[preset] Configure preset x86: No toolset version specified for cl.exe, using latest by default

and the x64 compiler is not selected, moving the preset selection to inside each derived preset does not work either.

Interestingly the architecture setting does seem to work even though "strategy" is not "external" (this is fine by me).

Also, in this example cmake tools is not selecting the latest toolset, I have vs 2022 installed and it's never selected, while the latest version of vs 2019 16.11 preview is selected for x86 and x64, and an older version of vs 2019 int preview is selected for arm and arm64, this could be sticky settings, but cmake tools does find all my VS installs when scanning for compilers.

[barcharcraz]

hmm after removing vs 2019 int preview the arm and arm64 presets don't even configure, referring to an non-existent compiler. and I get errors about kits pointing to deleted compilers. The thing is when preset mode is enabled all the options to edit kits are turned off! This seems wrong if the kits actually do influence compiler selection in preset mode.

[barcharcraz]

Indeed responding to the error about the missing compiler in a kit and reconfiguring the arm preset now selects the vs 2019 preview compiler that is installed. The toolset architecture is still wrong, however.

[JasonDictos]

Through much trial and error and source code diving, this is how I've silenced both of the above warnings:

Architecture:

"architecture": {
  "value": "x64",
  "strategy": "external"
},
"toolset": {
   "value": "version=16.11.31410.223,host=x64",
   "strategy": "external"
  },

Took too long to debug that version key, the code is here: https://github.com/microsoft/vscode-cmake-tools/blob/develop/src/preset.ts

Digging into it its parsing the toolset and architecture keys in the preset. They can both be a string, or an object. The version is from vswhere, example:

"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere" -all -format json -utf8 -products * -legacy -prerelease

[
  {
    "instanceId": "6a2ed37c",
    "installDate": "2021-05-18T20:08:12Z",
    "installationName": "VisualStudioPreview/16.11.0-pre.2.0+31410.223",
    "installationPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Preview",
    "installationVersion": "16.11.31410.223",

Now installationVersion is what they are comparing so you can select the host (what version of cl to use, e.g. 64 bit version) and the version of the toolset (in this case 16.11 preview 2). Architecture is well, how its being built that should trigger a vcvars call for the chosen architecture string if external.

[bobbrow]

I'm not sure why I didn't see this issue earlier, but in the presets example shared, the issue is that "x64" was being set for toolset instead of "host=x64". I actually just submitted a PR to add logging about what to do in this case which should hopefully resolve the problem for most folks in the future.

VS 2022 isn't supported by a released version of CMake yet. It's coming in version 3.21.

Is it too distracting to make those messages about toolset and version into "warnings"? Is the request that we lower the severity and make them "info" instead?

[barcharcraz]

I think the solution is to document what toolset and architecture actually do, in particular the docs should say things follow the CMAKE_GENERATOR_TOOLSET convention. Right now I think the docs are just incorrect.

I'm using the ninja generator so cmake's support for vs2022 project files is not relevant to me, cmake can identify the compiler version shipped in vs2022 just fine. Also I think the copy of cmake that comes with VS2022 may be a pre-release that supports generating vs2022 project files. I'm not sure though, I have to check.

[barcharcraz]

Oh, the request is that there should be some way to get the x64 toolset, and the documentation on how to do it should actually be correct. I'm not worried about the very presence of the warnings but about the fact that I couldn't figure out how to actually set the toolset arch

[bobbrow]

There is a way to get the x64 toolset. You use:

  "toolset": {
    "value": "host=x64",
    "strategy": "external"
  }

This aligns with the CMake documentation. Previously, with Kits and Variants the extension patched up the syntax for you if you missed the "host=" part. We didn't do this for CMakePresets.json because CMake and VS would reject it and it would only work in VS Code.

Can you point out what's wrong with the documentation on toolset? I was just looking at it and didn't see anything wrong. It points to the CMake documentation for Toolset selection.

[barcharcraz]

I think I was confused by

You can set the host architecture (x64 or x86) and toolset by using toolset.value. This is equivalent to passing -T to CMake from the command line. For more information, see Toolset Selection.

from https://github.com/microsoft/vscode-cmake-tools/blob/develop/docs/cmake-presets.md

The problem with "stale" kits may still be an actual bug.

[bobbrow]

I'll talk to the team about re-enabling the "edit kits" command when presets are in use. Since we do use them to configure the MSVC environment in some cases, I also found it a pain to switch back to "cmake.usePresets": "never" to get the command to reappear.

[barcharcraz]

will "cmake.usePresets": "never" cause cmaketools to totally disable reading from the cmakePresets.json file? If so that's not what I want at all! The whole point is to make things more consistent and replace our CMakeSettings.json file.

Thanks for looking into re-enabling that command though!

[barcharcraz]

cmake tools can not find the copy of Ninja installed as part of my visual studio installation, Ninja must be on that path.

This is a little unexpected, and cmake-tools should probably provide some option to use the ninja from the selected compiler

Also, your example of

"architecture": {
  "value": "x64",
  "strategy": "external"
},
"toolset": {
   "value": "version=16.11.31410.223,host=x64",
   "strategy": "external"
  },

implies that the versions accepted by cmake tools differ from the versions accepted by the vsdevcommand and cmake. I think the latest toolset version is 14.30.30401.

Further I still get issues with:

{
    "version": 2,
    "configurePresets": [
        {
            "name": "base",
            "hidden": true,
            "generator": "Ninja",
            "binaryDir": "${sourceDir}/out/build/${presetName}",
            "cacheVariables": {
                "CMAKE_CXX_COMPILER": "cl.exe",
                "CMAKE_C_COMPILER": "cl.exe",
                "CMAKE_BUILD_TYPE": "Debug"
            }
        },
        {
            "name": "x86",
            "inherits": "base",
            "architecture": {
                "value": "x86",
                "strategy": "external"
            },
            "toolset": {
                "value": "host=x64",
                "strategy": "external"
            }
        }
   ]
}

It's selecting the x86 version of vs2019, when I would expect the x64 version of vs2020, or at least hte x64 version of something

[barcharcraz]

Actually, it occurs to me that the toolset selected should not influence which vs version cmake tools picks at all, since you can very well install have the same toolset installed in multiple different VS installs.

I would expect the toolset to result in the compiler I get when running vsdevcmd -arch=x86 -host_arch=amd64 -vcvars_ver=<whaever I put in verson=, exactly>

[srnwk]

It would be really handy if this could would work with the same syntax in both Visual Studio and vscode-cmake-tools,
otherwise you will need a bunch of duplicated, near-identical presets for doing the same thing in VS and VSCode 😬

[bobbrow]

Sorry this fell off my radar. To summarize the current issue since this thread has meandered a few different ways:

• The toolset version is not correctly handled. It is being interpreted by CMake Tools as the VS version, but it should be interpreted as the Toolset version (which is unfortunately divergent). This has the result of making presets that specify a version incompatible between VS/CMake and VS Code.

Does that sound right? Is there anything else?