[CMake] MSVC71 problems when upgrading to CMake 2.6.2

[Luke Kucalaba]

Thanks for the links.  I had never seen that CMake_2.6_Notes page
before... I don't see it linked from the CMake Wiki home or CMake main
website.

It sounds like the whole concept of build configurations has been
upgraded with 2.6.  In my situation, I would want to use the "set target
properties" method because we are already using that method for
Unix/NMake style target-based builds.  

In the unix world, we have a "debug" target and a "release" target for
each library and executable that we build (with debug having "-dbg"
suffix).  In the MSVC world (using CMake 2.4.7), we have a single
"project" target that has "debug" and "release" build configurations
(where the DEBUG_OUTPUT_NAME is set to "-dbg" suffix), which uses the
CMAKE_*_FLAGS_<CONFIG> variables.

I have two major problems with making the change to use target-based
project generation for MSVC.  First problem is that you will still have
build configurations in your MSVC project regardless.  There is no way
that I know of to disable generation of build configurations in MSVC.
I've tried every permutation that I know of to set the
CMAKE_CONFIGURATION_TYPES variable to customize this but I've never had
any success.  So that means you would generate an MSVC project file for
every target (ie "debug" and "release" targets), and then in turn each
project file has its own build configurations (Debug, Release,
RelWithDebugInfo, MinSizeRel).  Not only is this is extraordinarily
confusing but also makes it difficult to use the "Batch Build" feature
without manually deselecting half the configurations in the list.  Not a
big deal until you consider that we have around 30 targets which now
have 4 build configurations each, and 10 programmers which adds up to a
lot of time wasted in confusion and extra build overhead.

The second problem I have with this target-based approach is that the
"set target properties" command does not allow exclusive, direct
command-line manipulation of the compiler and linker.  There are is no
COMPILE_FLAGS_DEBUG and COMPILE_FLAGS_RELEASE properties.  It is nice
that   I see that there ARE properties for LINK_FLAGS_DEBUG and
LINK_FLAGS_RELEASE though.  The main reason we had to use, for instance,
the CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE variables is so
that we could pass custom flags to the compiler/linker.  Here are a
couple examples of what I mean by this (btw, these are our own CMake
custom macro calls):

 
Add_Command_Line_Arguments(${PROJECT}_COMPILER_ARGS_DEFAULT_DEBUG
            "/W3"       # Warning level 3
            "/Wp64"     # Check for 64-bit compatibility issues
            "/c"        # Compile without linking
            "/TP"       # Compile as C++ code
            "/EHsc"     # Enable C++ exceptions
            "/Od"       # Disable optimization
            "/ZI"       # Program database for edit & continue
            "/RTC1"     # Basic run-time error checks
            "/Gm"       # Enable minimum rebuild
            "/Gy"       # Function-level linking (required for edit &
continue)
            "/GF"       # Enable read-only string pooling (optimization)
            "/GS"       # Buffer security check
            "/nologo"   # Suppress Microsoft copyright banner
        )
    
 
Add_Command_Line_Arguments(${PROJECT}_COMPILER_ARGS_DEFAULT_RELEASE
            "/W3"       # Warning level 3
            "/Wp64"     # Check for 64-bit compatibility issues
            "/c"        # Compile without linking
            "/TP"       # Compile as C++ code
            "/EHsc"     # Enable C++ exceptions
            "/O2"       # Optimize for maximum speed
            "/arch:SSE2" # Use SSE2 instructions in code generation
            "/GL"       # Enables whole program optimization
            "/nologo"   # Suppress Microsoft copyright banner
        )

        Add_Command_Line_Arguments(${PROJECT}_LINKER_ARGS_DEFAULT_DEBUG
            "/NOLOGO"               # Suppress Microsoft copyright
banner
            "/MACHINE:X86"          # Specifies the target machine
        )
        
 
Add_Command_Line_Arguments(${PROJECT}_LINKER_ARGS_DEFAULT_RELEASE
            "/NOLOGO"               # Suppress Microsoft copyright
banner
            "/MACHINE:X86"          # Specifies the target machine
            "/OPT:REF"              # Eliminates functions and/or data
that are never referenced
            "/OPT:ICF"              # Used to perform identical COMDAT
folding 
            "/LTCG"                 # Specifies link-time code
generation
            "thrownew.obj"
        )

I think Bill Hoffman has already determined a solution, so for now I'll
just go with that, but eventually I'd like to move to the "preferred"
method of establishing MSVC build configurations (ie if "set target
properties" is the most recommended and best supported method then we
definitely want to use that in the long run).  But at this point, the
"set target properties" command just doesn't support all the properties
we need to set.

Thanks,
Luke        

-----Original Message-----
From: Brad King [mailto:brad.king at kitware.com] 
Sent: Thursday, October 09, 2008 1:39 PM
To: Luke Kucalaba
Cc: cmake at cmake.org
Subject: Re: [CMake] MSVC71 problems when upgrading to CMake 2.6.2

Luke Kucalaba wrote:
> the strategy we
> have used to set the compiler definitions for each build configuration

CMake 2.6 provides an explicit feature for this:

http://www.cmake.org/Wiki/CMake_2.6_Notes#Preprocessor_Definitions
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_dir:COMPILE_DEFIN
ITIONS
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_dir:COMPILE_DEFIN
ITIONS_CONFIG
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFIN
ITIONS
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:COMPILE_DEFIN
ITIONS_CONFIG

-Brad