[CMake] VS2005: CMAKE_CXX_FLAGS not used when project() is placed after definition

[Michael Hertling]

On 09/20/2011 03:40 PM, Jens Auer wrote:
> Hi,
> 
> I encountered a problem with CMAKE_CXX_FLAGS and the place in the CMakeLists.txt where the project() command is placed. Consider two CMakeLists.txt files, the first containing
> 	SET(CMAKE_CXX_FLAGS "/EHa /O2")
> 
> 	project(CMAKE_BUG)
> 
> 	add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")
> 
> And the second containing
> 
> 	project(CMAKE_BUG)
> 
> 	SET(CMAKE_CXX_FLAGS "/EHa /O2")
> 
> 	add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")
> 
> When I run cmake 2.8.5 on both files, the exception handling option differs. For the first file, it is set to 1 in the generated VS project file, which means /Ehsc, the default. The second file generates the intended project file with windows structured exceptions enabled.
> 
> I only checked the generated VS2005 files, so I don't know if this is an issue of this specific generator or a more global one.
> 
> Best regards,
>   Jens

The PROJECT() command has significant side effects, e.g. for C++
projects, it loads Modules/CMakeCXXInformation.cmake containing:

SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_INIT}" CACHE STRING
     "Flags used by the compiler during all build types.")

If CMAKE_CXX_FLAGS has no value in the cache before, this command will
write to the cache *and* to the current scope, see [1]. Thus, it will
overwrite the value provided in the CMakeLists.txt in the first case.
In the second case, the CMakeLists.txt file provides the definitive
value in the current scope which will be in effect afterwards.

IMO, it's best to have PROJECT() as one of the very first commands
in CMakeLists.txt files, and to only put other commands before it
if one really knows about the consequences.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg29869.html