Comparing Visual Studio IDE default release build vs CMake default release build

Hello,

I am trying to transition from Visual Studio IDE’s vcxproj project files and embrace CMake.
By default, Visual Studio’s release mode comes with the following settings:

UseDebugLibraries	         false
WholeProgramOptimization     true
LinkIncremental	             false
GenerateManifest	         false
ClCompile	
    IntrinsicFunctions	     true
    FunctionLevelLinking     true
    Optimization	         MaxSpeed
    SDLCheck	             false
    ConformanceMode	         true
    BufferSecurityCheck	     false
    DebugInformationFormat   None
Link	
    GenerateDebugInformation false
    EnableCOMDATFolding	     true
    OptimizeReferences	     true

I do not have anything special in my CML.txt expecting that the default release build of CMake should track the default release build of Visual Studio in terms of settings/compiler flags/linker flags. Given this what I believe is a reasonable expectation, I am somewhat taken aback by a comment made to a similar question I posed over at /r/cmake here

Whole Program Optimization, for instance, is not enabled by CMake release builds by default (check out INTERPROCEDURAL_OPTIMIZATION in CMake if you want to enable it).

Is there any documentation available on how one can reconcile release build differences between Visual Studio and CMake’s release builds both for usage under MSVC?

At present, my solution to this problem of incompatible flags is to force the following into my CML.txt file based on going through Visual Studio IDE’s project settings and noting down the flags and then forcing them into my CML.txt [in comments are the setting in Visual Studio IDE to access the relevant properties natively ] :

if(MSVC)
    if (CMAKE_BUILD_TYPE STREQUAL "Release")
        target_compile_options(CMakeProject PUBLIC "/sdl-")
        # C/C++ -> General -> SDL Checks
        target_compile_options(CMakeProject PUBLIC "/permissive-")
        # C/C++ -> Language -> Conformance Mode -> Yes
        target_compile_options(CMakeProject PUBLIC "/GL")
        # C/C++ -> Optimization -> Whole program optimization
        target_compile_options(CMakeProject PUBLIC "/Oi")
        # C/C++ -> Optimization -> Enable Intrinsic Functions
        target_compile_options(CMakeProject PUBLIC "/GS-")
        # C/C++ -> Code Generation -> Security Check -> Disable Security Check
        target_compile_options(CMakeProject PUBLIC "/Gy")
        # C/C++ -> Code Generation -> Enable Function Level Linking
        target_link_options(CMakeProject PUBLIC "/MANIFEST:NO")
        # Linker -> Manifest file -> Generate Manifest -> No
        target_link_options(CMakeProject PUBLIC "/OPT:REF")
        # Linker -> Optimization -> References -> Yes
        target_link_options(CMakeProject PUBLIC "/OPT:ICF")
        # Linker -> Optimization -> Enable COMDAT Folding -> Yes
        target_link_options(CMakeProject PUBLIC "/INCREMENTAL:NO")
        # Linker -> General -> Enable Incremental Linking -> No
    endif()
endif()

This seems like a hackish way of doing it and I am wondering if there is a better simpler way to attain parity between default release mode builds of CMake and native Visual Studio IDE for MSVC.

Thank you.

CMake doesn’t aim to match arbitrary IDE settings collections like that. What you have looks to be the way to do it (except where CMake has abstractions like interprocedural optimization).

1 Like

CMake doesn’t aim to match arbitrary IDE settings collections like that.

Thanks for the information. Although, if I might add, it is not a collection of arbitrary IDE settings. It is actually just merely the out-of-the-box default Release build settings of Visual Studio IDE with no user changes/modifications applied on top.

The “arbitrary” was intended to go with “IDE”, not “settings”. English lacks rigorous operator precedence :frowning: .

:grinning:

Fair enough. Still, VS is not an arbitrary IDE. Quite possibly, atleast on Windows, it is the most popular IDE/compiler toolkit.

I do not want to stretch the discussion further than this.

Thanks for CMake developers though. I am able to cross build the same code on Linux using VSCode also with minimal fuss.