[CMake] VC++10 change WIN32_EXECUTABLE per configuration

[David Cole]

Also,

see this outstanding "bug" report:

  http://public.kitware.com/Bug/view.php?id=12566


On Tue, Jul 31, 2012 at 7:42 AM, David Cole <david.cole at kitware.com> wrote:
> CMAKE_BUILD_TYPE is not set for Visual Studio or Xcode generators...
>
> It's a build-time choice.
>
>
> On Tue, Jul 31, 2012 at 5:03 AM, Brett Delle Grazie
> <brett.dellegrazie at gmail.com> wrote:
>> On 31 July 2012 01:05, Steve deRosier <derosier at gmail.com> wrote:
>>> I need a way to have the WIN32_EXECUTABLE property set off for debug
>>> builds and on for release builds when using the IDE.
>>>
>>> Here's the deal: For debug our code uses the standard main()
>>> construct, and for release we use the WinMain(). Lets just say there's
>>> a reason and leave it at that...
>>> The obvious solution is to be able to specify the '/subsystem:windows'
>>> flag myself in LINK_FLAGS_DEBUG and LINK_FLAGS_RELEASE.
>>>
>>> But, the generator overrides these settings for me.  So, I found the
>>> WIN32 for add_executable(), but of course you can't specify that
>>> differently for debug vs release.
>>>
>>> For a make-file generator, I could just utilize:
>>> if( "${CMAKE_BUILD_TYPE}" STREQUAL "Debug" )
>>> ...
>>> elseif( "${CMAKE_BUILD_TYPE}" STREQUAL "Release" )
>>> ...
>>> endif()
>>>
>>> but of course this doesn't work when generating for VS10 IDE.
>>>
>>> I found the CMAKE_CREATE_WIN32_EXE variable, but overriding it to ""
>>> does nothing, so I resorted to looking at cmake's source code, which
>>> totally ignores that variable, and hard codes the linker flag in the
>>> output based on the WIN32_EXECUTABLE property! (see line 1409 of
>>> cmVisualStudio10TargetGenerator.cxx).
>>>
>>> OK, other than hacking the cmake source and rolling our own, so is
>>> there any way to:
>>> 1. Override the setting after-the-fact but before the project files
>>> are actually written?
>>> 2. Set the WIN32_EXECUTABLE property on a per-configuration basis?
>>>
>>> At the moment I see four options-> hack the cmake source and roll our
>>> own; do some post-processing on the produced project files; Force
>>> everyone to manually change the flag in the IDE; convince my client to
>>> restructure some code so we don't encounter this problem in the first
>>> place.
>>>
>>> I'm hoping there's more options out there that are pure project.cmake
>>> file-based. Anyone?
>>
>> How about just defining two different projects:
>>
>> if (CMAKE_BUILD_TYPE STREQUAL "Debug")
>>   add_executable( sample_debug ${sample_SRCS})
>> else()
>>   add_executable( sample_release WIN32 ${sample_SRCS})
>> endif()
>>
>> caveat empor: completely untested and off the top of my head.  Could
>> also use MATCHES in the if condition in case you have other build
>> types
>>
>>>
>>> Thanks,
>>> - Steve
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>>
>> --
>> Best Regards,
>>
>> Brett Delle Grazie
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake