Issue
Visual Studio generated the following CMakePresets.json for me when I click on "Manage Configurations..." in a CMake project:
{
"version": 3,
"configurePresets": [
{
"name": "windows-base",
"description": "Target Windows with the Visual Studio development environment.",
"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",
"description": "Target Windows (64-bit) with the Visual Studio development environment. (Debug)",
"inherits": "windows-base",
"architecture": {
"value": "x64",
"strategy": "external"
},
"cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" }
},
{
"name": "x64-release",
"displayName": "x64 Release",
"description": "Target Windows (64-bit) with the Visual Studio development environment. (RelWithDebInfo)",
"inherits": "x64-debug",
"cacheVariables": { "CMAKE_BUILD_TYPE": "Release" }
},
{
"name": "x86-debug",
"displayName": "x86 Debug",
"description": "Target Windows (32-bit) with the Visual Studio development environment. (Debug)",
"inherits": "windows-base",
"architecture": {
"value": "x86",
"strategy": "external"
},
"cacheVariables": { "CMAKE_BUILD_TYPE": "Debug" }
},
{
"name": "x86-release",
"displayName": "x86 Release",
"description": "Target Windows (32-bit) with the Visual Studio development environment. (RelWithDebInfo)",
"inherits": "x86-debug",
"cacheVariables": { "CMAKE_BUILD_TYPE": "Release" }
}
]
}
I'm interested in the cmake install prefix, which is set with the installDir
field. It is nice because the resulting directory will indirectly include the processor name "x64" since the preset name includes the processor.
But the processor name is hardcoded, i.e. it is part of the string literal, e.g. "x64-debug"
, in the various preset names. Is it possible to reference the processor as a variable (or macro expansion) in CMakePresets.json? I.e. something similar to the CMAKE_SYSTEM_PROCESSOR
cache variable that is available in CMakeLists.txt?
Solution
No it is not. The full list of available macros can be found here.
It is currently limited to
${sourceDir}
: Path to the project source directory (i.e. the same asCMAKE_SOURCE_DIR
).${sourceParentDir}
: Path to the project source directory's parent directory.${sourceDirName}
: The last filename component of${sourceDir}
. For example, if${sourceDir}
is/path/to/source
, this would besource
.${presetName}
: Name specified in the preset'sname
field.${generator}
: Generator specified in the preset'sgenerator
field. For build and test presets, this will evaluate to the generator specified byconfigurePreset
.${hostSystemName}
:The name of the host operating system. Contains the same value asCMAKE_HOST_SYSTEM_NAME
. This is allowed in preset files specifying version 3 or above.${fileDir}
: Path to the directory containing the preset file which contains the macro. This is allowed in preset files specifying version 4 or above.${dollar}
: A literal dollar sign ($).${pathListSep}
: Native character for separating lists of paths, such as:
or;
. For example, by settingPATH
to/path/to/ninja/bin${pathListSep}$env{PATH}
,${pathListSep}
will expand to the underlying operating system's character used for concatenation inPATH
. This is allowed in preset files specifying version 5 or above.$env{<variable-name>}
: Environment variable with name<variable-name>
. The variable name may not be an empty string. If the variable is defined in theenvironment
field, that value is used instead of the value from the parent environment. If the environment variable is not defined, this evaluates as an empty string. Note that while Windows environment variable names are case-insensitive, variable names within a preset are still case-sensitive. This may lead to unexpected results when using inconsistent casing. For best results, keep the casing of environment variable names consistent.$penv{<variable-name>}
: Similar to$env{<variable-name>}
, except that the value only comes from the parent environment, and never from theenvironment
field. This allows you to prepend or append values to existing environment variables. For example, settingPATH
to/path/to/ninja/bin:$penv{PATH}
will prepend/path/to/ninja/bin
to thePATH
environment variable. This is needed because$env{<variable-name>}
does not allow circular references.$vendor{<macro-name>}
: An extension point for vendors to insert their own macros. CMake will not be able to use presets which have a$vendor{<macro-name>}
macro, and effectively ignores such presets. However, it will still be able to use other presets from the same file. CMake does not make any attempt to interpret$vendor{<macro-name>}
macros. However, to avoid name collisions, IDE vendors should prefix<macro-name>
with a very short (preferably <= 4 characters) vendor identifier prefix, followed by a.
, followed by the macro name. For example, the Example IDE could have$vendor{xide.ideInstallDir}
.
Answered By - Corristo Answer Checked By - Gilberto Lyons (WPSolving Admin)