[CMake] Custom configuration types in Visual Studio

[Michael Hertling]

On 01/17/2012 11:12 PM, Robert Dailey wrote:
> Is it a bug that project() does not append to the user-specified
> configurations? Sure seems like one...

Hmm, not really: How should PROJECT() differentiate if the user wants
to augment the list of configurations or to replace it completely?
ATM, that's not possible, so you have the choice only between

- setting CMAKE_CONFIGURATION_TYPES before PROJECT(), i.e. replace,
- appending to CMAKE_CONFIGURATION_TYPES after PROJECT() - invoked
  without languages - but before ENABLE_LANGUAGE(), i.e. augment.

This is because Modules/Platform/Windows-cl.cmake et al. use

SET(CMAKE_CONFIGURATION_TYPES "..." CACHE STRING "...")

which is a no-op if CMAKE_CONFIGURATION_TYPES is already set, so you
can replace CMake's standard configurations by your own ones. OTOH,
AFAIK, these files are loaded by PROJECT(), but enabled along with
the languages, so there's the opportunity to modify the list of
configurations between PROJECT() and ENABLE_LANGUAGE().

If you want to have both possibilities available all at once, look at
the attached patch. The USER_CONFIGURATION_TYPES variable allows for
the specification of additional configurations before PROJECT(), so
you can easily augment the list, and if you want to replace it, you
can do so as usual by presetting CMAKE_CONFIGURATION_TYPES in the
cache. Possibly, Modules/Platform/Windows-{df,ifort}.cmake would
need such a patch, too. Feel free to file a feature request.

Regards,

Michael

> On Fri, Jan 13, 2012 at 4:52 PM, Michael Hertling <mhertling at online.de>wrote:
> 
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Windows-cl.cmake.diff
Type: text/x-diff
Size: 783 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120127/746bab1d/attachment.diff>