How does CMake handle the versions of CMakePresets versus CMakeUserPresets? Does the version have to be the same?
If not, which version takes precedence?
If so, does it simply exit with an error because the versions didn’t match?
Any insight into this would be great!
You should be able to use different versions for CMakePresets.json and CMakeUserPresets.json. CMake should be interpreting each file according to its own version field. The version applies just to that file, one file’s version doesn’t override another.
There was a period where some IDEs didn’t handle this situation correctly, but I don’t know what the current state of that is (I think the bug I’m thinking of got fixed).
Hi @craig.scott ! I’m finally getting back around to investigating this. I’m asking this because I believe I’m noticing some inconsistencies with this from the CMake command-line.
If I have the following CMakePresets.json file:
{
"version": 3,
"configurePresets": [
{
"name": "windows-base",
"hidden": true,
"generator": "Ninja",
"binaryDir": "${sourceDir}/out/build/${presetName}",
"installDir": "${sourceDir}/out/install/${presetName}",
"cacheVariables": {
"CMAKE_C_COMPILER": "cl.exe",
"CMAKE_CXX_COMPILER": "cl.exe"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Windows"
}
},
{
"name": "x64-debug",
"displayName": "x64 Debug",
"inherits": "windows-base",
"architecture": {
"value": "x64",
"strategy": "external"
},
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
}
},
{
"name": "x64-release",
"displayName": "x64 Release",
"inherits": "x64-debug",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Release"
}
},
{
"name": "x86-debug",
"displayName": "x86 Debug",
"inherits": "windows-base",
"architecture": {
"value": "x86",
"strategy": "external"
},
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
}
},
{
"name": "x86-release",
"displayName": "x86 Release",
"inherits": "x86-debug",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Release"
}
},
{
"name": "linux-debug",
"displayName": "Linux Debug",
"generator": "Ninja",
"binaryDir": "${sourceDir}/out/build/${presetName}",
"installDir": "${sourceDir}/out/install/${presetName}",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Linux"
},
"vendor": {
"microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
"sourceDir": "$env{HOME}/.vs/$ms{projectDirName}"
}
}
},
{
"name": "macos-debug",
"displayName": "macOS Debug",
"generator": "Ninja",
"binaryDir": "${sourceDir}/out/build/${presetName}",
"installDir": "${sourceDir}/out/install/${presetName}",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Darwin"
},
"vendor": {
"microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
"sourceDir": "$env{HOME}/.vs/$ms{projectDirName}"
}
}
}
]
}
and the following CMakeUserPresets.json
{
"version": 2,
"configurePresets": [
{
"name": "windows-User-default",
"inherits": "windows-base",
"displayName": "x64 Debug",
"description": "Target Windows with the Visual Studio development environment.",
"binaryDir": "${sourceDir}/out/build/${presetName}",
"architecture": {
"value": "x64",
"strategy": "external"
},
"vendor": { "microsoft.com/VisualStudioSettings/CMake/1.0": { "hostOS": [ "Windows" ] } }
}
]
}
I get the following output on the command line from CMake:
Is there something that is being handled wrong or something that I’m misunderstanding?
@kyle.edwards What do we expect to happen here? The CMakeUserPresets.json file only directly uses things from presets schema version 2. The windows-User-default configure preset inherits from windows-base, which is defined in CMakePresets.json. The windows-base preset uses${hostSystemName} in its condition, which is from schema version 3. Putting aside for the moment that this will break on all platforms except Windows (more on that below), should this technically work on Windows at least?
@gcampbell-msft My understanding is that if you have a derived preset, it cannot inherit from a base preset that has a condition which may result in the derived preset being accepted, but the condition in the base preset being rejected. In other words, I think you would have to repeat the condition in the derived preset as well. I don’t think making a base preset fail a condition works transitively to also make derived presets be seen to fail a condition. I think that’s technically an error. I can very much understand why it might be desirable for it to work that way, but I don’t think that’s how it is implemented. @kyle.edwards would likely have a better understanding and know if my comments here are correct.
