[CMake] Determining debug & release configurations

[Robert Dailey]

Thanks for the tips...

I think this might be a little overkill, because the solution I was
looking at involved the DEBUG_CONFIGURATIONS variable. For
multi-configuration generators, you can see if any items in
CMAKE_CONFIGURATION_TYPES match what's inside of DEBUG_CONFIGURATIONS.
Any match is a DEBUG configuration, anything that doesn't match is
RELEASE.

I don't know for sure if this works for single-configuration
generators, where I'd check CMAKE_BUILD_TYPE against
DEBUG_CONFIGURATIONS. But I was hoping someone would comment on how to
do this for single-configuration generators.

Thanks in advance...

On Fri, Dec 7, 2012 at 3:38 AM, Andreas Mohr <andi at lisas.de> wrote:
> Hi,
>
> On Fri, Dec 07, 2012 at 04:01:27AM -0500, cmake-request at cmake.org wrote:
>> Date: Thu, 6 Dec 2012 11:54:42 -0600
>> From: Robert Dailey <rcdailey.lists at gmail.com>
>
>> Does anyone have any code that can detect if a given configuration (by
>> name) is a debug or release configuration? This should work in both
>> single-configuration and multi-configuration generators.
>>
>> For example, in Visual Studio:
>>
>> Release -> Release
>> MinSizeRel -> Release
>> RelWithDebInfo -> Release
>> Debug -> Debug
>>
>> Also any custom-added configurations should also work.
>>
>> For single configuration generators, it should also work. Example:
>>
>> CMAKE_BUILD_TYPE -> MinSizeRel -> should evaluate to "Release".
>> CMAKE_BUILD_TYPE -> Debug -> should evaluate to "Debug".
>
> That's quite exactly what I'm doing right now (*dynamic*, *build-time*
> calculation of required, *random-content* flag strings).
>
> My solution (workaround?) is to provide functions to return a Win32 batch scriptlet
> to automatically map those config names to their equivalents,
> then continue filling batch file with what I actually want to do,
> making use of the %var% helpers which were nicely defined by the prepended scriptlet code.
>
> And of course that unfortunately means having to generate batch files to be executed
> rather than possibly adding custom targets with direkt cmake -E copy.... handling.
>
>
> But of course with a complex mapping of *dynamic* Debug/Release switching at *build-time*
> you most likely do need to have a build-executable foundation to get this figured out properly.
> Unless you write completely differing *static-content* scripts,
> located in completely differing build tree prefixes of Debug/Release configurations.
> That's possibly a better solution since with dynamic switching
> within an existing tree of payload files
> you may end up getting unwanted build configuration conflicts.
>
> Actual possible implementation: add a scripts_[BUILD_CONFIGURATION] dir
> somewhere in binary dir, for all configurations that you of course know of at configure time
> (CMAKE_CONFIGURATION_TYPES).
> Then configure-time generate
> only-so-slightly differing scripts there, and invoke them using some
>
> ${CMAKE_SOME_BINARY_SUB_DIR}/scripts_${CMAKE_CFG_INTDIR}/my_script.bat
>
> expression.
>
>
>
> Helper functions suitable for *dynamic* (i.e., non-configure-time-generated)
> evaluation of build-configuration-related values:
>
>
> function(sbuild_configure_batch_var_name_debug_release_string_lower_get _out)
>   set(${_out} "cfg_build_string_debug_release" PARENT_SCOPE)
> endfunction(sbuild_configure_batch_var_name_debug_release_string_lower_get _out)
> function(sbuild_configure_batch_var_name_debug_yes_no_get _out)
>   set(${_out} "cfg_build_debug_yes_no" PARENT_SCOPE)
> endfunction(sbuild_configure_batch_var_name_debug_yes_no_get _out)
>
> function(sbuild_configure_batch_scriptlet_debug_flag_get _out_debug_flag_content)
>   # Provide DOS batch syntax to support dynamic Debug/Release switching in multi-configuration generators (Visual Studio) [see CMAKE_CONFIGURATION_TYPES]
>
>   # Within local handling, *always* query the authoritative helper for batch variable names,
>   # to prevent any variable renaming issues from appearing.
>   sbuild_configure_batch_var_name_debug_yes_no_get(var_name_debug_yes_no)
>   sbuild_configure_batch_var_name_debug_release_string_lower_get(var_name_debrel_string_lower)
>   set(sbuild_configure_batch_debug_flag_content "
> set build_config=%1
> echo \"%0: build config: %build_config%\"
>
> if \"%build_config%\" == \"Release\" goto cfg_release
> if \"%build_config%\" == \"Debug\" goto cfg_debug
> if \"%build_config%\" == \"RelWithDebInfo\" goto cfg_release
> if \"%build_config%\" == \"MinSizeRel\" goto cfg_release
>
> echo \"Unknown build configuration (%build_config%), please add support!\"
>
> rem fall-through to default Release setting (default should always be non-debug! don't leak debug symbols...)
>
> rem Provide several very different variables, to satisfy any and all potential flag requirements
> rem of various build environments
>
> :cfg_release
> set ${var_name_debug_yes_no}=no
> set cfg_build_debug_enabled_int=0
> set cfg_build_release_yes_no=yes
> set cfg_build_release_enabled_int=1
> set ${var_name_debrel_string_lower}=release
> goto cfg_build_flags_done
>
> :cfg_debug
> set ${var_name_debug_yes_no}=yes
> set cfg_build_debug_enabled_int=1
> set cfg_build_release_yes_no=no
> set cfg_build_release_enabled_int=0
> set ${var_name_debrel_string_lower}=debug
> goto cfg_build_flags_done
>
> :cfg_build_flags_done
>
> "
>   )
>
>   set(${_out_debug_flag_content} "${sbuild_configure_batch_debug_flag_content}" PARENT_SCOPE)
> endfunction(sbuild_configure_batch_scriptlet_debug_flag_get _out_debug_flag_content)
>
>
>
> HTH,
>
> Andreas Mohr
>
> --
> GNU/Linux. It's not the software that's free, it's you.