[CMake] Determining debug & release configurations

[Robert Dailey]

Is there no solution to this based on my assumptions?

On Mon, Dec 10, 2012 at 11:07 AM, Robert Dailey
<rcdailey.lists at gmail.com> wrote:
> 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.