Please add this functionality. It is useful for deduplication of config when specifying cache or environment variables for extra tools like code coverage (Bullseye coverage COVFILE) or static code analysis (SonarQube wrapper output dir)
binaryDir already supports macro expansion, as noted in the documentation:
An optional string representing the path to the output binary directory. This field supports macro expansion.
Sorry Kyle, I meant the other way around. binaryDir should be a macro that can be used in other fields.
1 Like
I don’t understand how this is NOT a thing already. Consider the following use case. I don’t want to set the build dir by the preset, that will be set by where ever the user wants, but I want the preset to add the following variable that is relative to the chosen build dir e.g.:
“CMAKE_PREFIX_PATH”: “${buildDir}/conan”
So I can seamlessly use the find dependency provider for conan 1 in this case if the user chooses said preset. I also like using the out-of-source builds, which means that the build dir is not relative to ${sourceDir} thus I need a ${buildDir}.
The build directory can be specified outside of the presets. For example, the user might add a -B option on the cmake command line. I can certainly see the attractiveness of having something like ${buildDir} available, but it technically isn’t something the preset can know.
I’ve used ${sourceParentDir} for exactly that purpose.
Sorry, that does not work with workflow presets!
bash-3.2$ cmake -B build --workflow --preset ci-clang
CMake Error: Unknown argument --workflow
CMake Error: Run 'cmake --help' for all supported options.
bash-3.2$ cmake -S . -B build --workflow --preset ci-clang
CMake Error: Unknown argument --workflow
CMake Error: Run 'cmake --help' for all supported options.
bash-3.2$
``The user setting the -B parameter on the command line is exactly why I would like to have it in as a macro expansion in the preset. I would like the preset to “fill in the blanks” after the user sets where he wants the build to go. In my case to set the CMAKE_PREFIX_PATH to somewhere I know the dependency provider will generate config files. And the deps provider is also set via this top-level include var in the preset. So the CMakeLists doesn’t know so I can’t/don’t want to put the prefix in there. But maybe my hopes were too high. So you are telling me that my only hope is to basically set the build dir also via the preset, preferably to something like ${sourceParentDir}/build?
This was how I wanted to use it so from my point of view the build dir could be known in time the preset is loaded.
cmake -S .\code\ -B .\build\ --preset current
I haven’t looked much into the workflows. I’m just doing baby steps with presets now 
Thanks very much for the answers
We already have an existing problem where we offer a macro expansion that can be overridden outside of the presets, but the macro expansion doesn’t give the correct final value. The ${generator} macro expands to what the presets resolve the generator too, but if the user overrides that with a -G option on the cmake command line, ${generator} won’t reflect the user’s override, it still expands to the preset-determined value.
@kyle.edwards would be more familiar with the internals, but I assume the presets are resolved before the other cmake command line options are processed. I assume this is so that the command line options will override the presets. If the command line values are needed to resolve the presets, then we have somewhat of a circular dependency.
What you want to do is reasonable, and I share your desire to be able to do what you have laid out. But the practicalities of the implementation may be trickier than it would naively seem.
1 Like