[CMake] CMAKE_CONFIGURATION_TYPES and PROJECT in macros - strange behavio ur

[Dekeyser, Kris]

Using CMake 2.0.5:
 
I have written a bunch of macros to make setting up the build as easy as possible. Amongst others I have created macros DDL_PROJECT(name), EXE_PROJECT(name) and LIB_PROJECT(name). Each of these macros will read some files in standard locations and derive settings for ADD_DEFINITIONS, LINK_LIBRARIES, INCLUDE_DIRECTORIES etc from it. In our environment most project's CMakeLists.txt contain only one line: eg "DLL_PROJECT(MyProjectName)".
 
This has worked fine for a long time, but now we start using VS.NET and I came into trouble. As our debug builds often need different defines, include dirs and libraries due to some 3rd party library constraints, we can support only one build configuration in the solution file. CMake handles this nicely by allowing us to set the variable CMAKE_CONFIGURATION_TYPES. But in combination with our macros we discovered some strange behaviour. The following code allows the evelopt to select the desired build type:
 
SET(BUILD_TYPE "Release" CACHE STRING "Build type (Debug/Release)")
 
STRING(TOUPPER ${BUILD_TYPE} U_BUILD_TYPE)
 
IF("${U_BUILD_TYPE}" STREQUAL "DEBUG")
  SET(CMAKE_BUILD_TYPES Debug RelWithDebInfo)
ENDIF("${U_BUILD_TYPE}" STREQUAL "DEBUG")
 
IF("${U_BUILD_TYPE}" STREQUAL "RELEASE")
  SET(CMAKE_BUILD_TYPES Release MinSizeRel)
ENDIF("${U_BUILD_TYPE}" STREQUAL "RELEASE")
 
SET (CMAKE_CONFIGURATION_TYPES "${CMAKE_BUILD_TYPES}" CACHE STRING "" FORCE)
MARK_AS_ADVANCED(CMAKE_CONFIGURATION_TYPES)
 
However, if we change the BUILD_TYPE in the GUI and reconfigure, the CMAKE_CONFIGURATION_TYPES is not overwritten, but appended to. After a couple of changes from and to debug and release we end up with CMAKE_CONFIGURATION_TYPES="Debug;Release;RelWithDebInfo;MinSizeRel". I added the following line to the end of the previous code for testing purposes:
 
SET (BUILD_TYPELIST "${CMAKE_BUILD_TYPES}" CACHE STRING "" FORCE)

and strange enough, the BUILD_TYPELIST setting IS correct.
 
I traced this down to the fact that the PROJECT setting is only done in the macro, but why is not clear to me. If I include a PROJECT setting directly in the CMakeLists.txt everything workes as expected.
 
WHY ????
 
PS Below is a simple example that shows the problem. Comment/Uncomment the PROJECT line in CMakeLists.txt to see the difference.
 
---- Contents of CMakeLists.txt
 
INCLUDE("includes.cmake")
 
#PROJECT(Test C++)
MY_PROJECT(Test)

---- Contents of includes.cmake
 
#--- The project macro
MACRO(MY_PROJECT Name)
 
  PROJECT(${Name} C++)
  
  ADD_EXECUTABLE(main main.c)
  
ENDMACRO(MY_PROJECT)
 
#--- Selects the type of build
SET(BUILD_TYPE "Debug" CACHE STRING "Build type (Debug/Release)")
SET (CMAKE_CONFIGURATION_TYPES "" CACHE STRING "")
 
STRING(TOUPPER ${BUILD_TYPE} U_BUILD_TYPE)
 
IF("${U_BUILD_TYPE}" STREQUAL "DEBUG")
  SET(CMAKE_BUILD_TYPES Debug RelWithDebInfo)
ENDIF("${U_BUILD_TYPE}" STREQUAL "DEBUG")
 
IF("${U_BUILD_TYPE}" STREQUAL "RELEASE")
  SET(CMAKE_BUILD_TYPES Release MinSizeRel)
ENDIF("${U_BUILD_TYPE}" STREQUAL "RELEASE")
 
#--- Set the other variables accoring to the selection above
SET (CMAKE_CONFIGURATION_TYPES "${CMAKE_BUILD_TYPES}" CACHE STRING "" FORCE)
 
SET (BUILD_TYPELIST "${CMAKE_BUILD_TYPES}" CACHE STRING "" FORCE)

+-+-+- Email Confidentiality Footer +-+-+- 
Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not print, retain, copy nor disseminate this message or any part of it to anyone and you should notify the sender by reply email and destroy this message. Neglecting this clause could be a breach of confidence. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that are not related to the official business of my firm shall be understood as neither given nor endorsed by it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20050209/c637ea95/attachment.htm