[CMake] Custom configuration types in Visual Studio

[Michael Hertling]

On 01/13/2012 05:06 PM, David Cole wrote:
> On Fri, Jan 13, 2012 at 10:22 AM, Michael Hertling <mhertling at online.de> wrote:
>> On 01/12/2012 10:23 PM, Robert Dailey wrote:
>>> I see there is documentation for this but it doesn't have an implementation
>>> for VS generators:
>>> http://www.cmake.org/Bug/view.php?id=5811
>>>
>>> Any status updates on this bug? I'd like to be able to create my own debug
>>> configuration called DebugStatic that uses the /MTd flag in all projects to
>>> link statically against the Microsoft libraries such as CRT.
>>>
>>> Any help?
>>
>> Look at the following exemplary project:
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>> PROJECT(P C)
>> SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
>>    CACHE STRING "" FORCE)
>> SET(CMAKE_C_FLAGS_DEBUGSTATIC "/MTd"
>>    CACHE STRING "" FORCE)
>> SET(CMAKE_EXE_LINKER_FLAGS_DEBUGSTATIC ""
>>    CACHE STRING "" FORCE)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
>> ADD_EXECUTABLE(main main.c)
>>
>> After "cmake <srcdir>" and a subsequent "cmake ." from within the build
>> directory, I can see the DebugStatic configuration appear in the VS IDE
>> when the generated solution is opened. Is this what you intend?
>>
>> However, I do not see DebugStatic when I open the solution right after
>> the initial configuration, i.e. without the reconfiguration step. Can
>> you confirm this behavior? Does anybody know why the reconfiguration
>> is necessary to make the custom configuration appear? This is with
>> CMake 2.8.7 and VS 2008.
>>
>> Regards,
>>
>> Michael
>> --
>>
>> 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
> 
> I don't know why it doesn't appear straight away, (although I suspect
> it's because the variable is set after the project command)

Yes, that's it; placing the SET() command for CMAKE_CONFIGURATION_TYPES
before PROJECT() makes the new configuration appear at once, but it is
*solely* the new one. Apparently, CMake's standard configurations are
defined by PROJECT() only if there aren't already any configurations
in the cache. A working alternative is to drop the language(s) from
PROJECT(), augment the list of configurations thereafter and use
ENABLE_LANGUAGE() finally, i.e.:

PROJECT(XYZ)  # <-- No language(s) here!
LIST(APPEND CMAKE_CONFIGURATION_TYPES ...)
LIST(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
    CACHE STRING "CMake configuration types" FORCE)
ENABLE_LANGUAGE(C)

> But you should never do this unconditionally:
> 
>   SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} DebugStatic
>     CACHE STRING "" FORCE)
> 
> That will simply continuously append to the variable in the cache, and
> it will grow on each subsequent configure in the same build tree...
> Real code should check whether DebugStatic is in there already, and
> avoiding appending if already present.

Uhhh... absolutely, bad mistake! Thanks for pointing this out.

Regards,

Michael