@bogong said in Detect current CMake configuration type. How?:
Why the simplicity of just "if-else" exchanged on complexity of the tricks of f-wording generators
There is no need for the kind of language here.
CMake is complex, because cross-platform build engineering is inherently complex. When you use a tool you need to understand it, and the fact that CMake has distinct configuration, generation and build phases (each with its' own way of specifying what should run at that phase) is often uncomfortable but important.
@bogong said in Detect current CMake configuration type. How?:
${CMAKE_BUILD_TYPE} variable. It's just empty.
@bogong said in Detect current CMake configuration type. How?:
In my project only XCode used
Xcode is exactly one of the generators that are multi-configuration (alongside MSBuild); where the same set of final build system files (i.e post configuration/generation) is used to make all build configuration. The variable is empty because variables are set during the configuration phase, and it wasn't set. As you shown, the actual build configuration is only passed to the cmake --build invocation - hence only available during the build phase.
This is pretty unavoidable, even if you try to manually pass -DCMAKE_BUILD_TYPE=Debug or something to CMake directly alongside -G Xcode to do a a manual CMake configuration, it will just be ignored. That's how Xcode project files work... If that's what Qt Creator's wrapper is doing, what Qt Creator shows is of no relevance.
Also see this note in CMake documentation: https://cmake.org/cmake/help/v4.1/generator/Xcode.html#limitations
@bogong said in Detect current CMake configuration type. How?:
For example for iOS for Debug - one Info.plist file for Release another one set of the files.
Even on generators that do support that (and again, Xcode doesn't) CMake doesn't make this pattern very easy - mostly because it is a bit of an abuse of the concept of build configurations. Configurations are meant to affect the flags that are passed to the build tools when making targets, not so much the shape of the dependency graph of the targets among themselves.
Luckily that's not what you are actually trying to do (although you appear to think so) - you don't want different files between build configurations, you want different content for the same file. That can certainly be done, with a custom build target. This is completely unrelated to Qt, but there are many examples around and if you want to delve into this the CMake Discourse site will be more appropriate place. You'll probably love the syntax even less than the one for generator expressions though... (not that you have much of a choice, really).
