Performing a CMAKE build with CMAKE_BUILD_TYPE=Release generates godot-cpp template_debug artifacts

[Naros]

Godot version

4.4.beta1

godot-cpp version

4.4.beta1 sync hash dfc5196

System information

Windows 11

Issue description

When building the latest godot-cpp based on commit hash dfc51960f9563c6df39a1a0ab66350374f932897, CMAKE uses template_debug although the parent project's CMAKE_BUILD_TYPE is set as Release, i.e.:

Building CXX object extern\godot-cpp\CMakeFiles\godot-cpp.template_debug.dir\gen\src\classes\audio_effect_phaser.cpp.obj
...
Building CXX object extern\godot-cpp\CMakeFiles\godot-cpp.template_debug.dir\gen\src\classes\audio_server.cpp.obj

I also confirmed the build type in my parent CMAKE as follows:

IF ($<CONFIG:Debug>)
    MESSAGE(STATUS "Debug build")
ELSE()
    MESSAGE(STATUS "Release build")
ENDIF()

which outputs

-- Release build

In addition, here are some environment settings my build sets and outputs:

Project Configuration Settings: orchestrator
=============================================

Build Configuration
    CMAKE_SYSTEM_PROCESSOR:..................: AMD64
    CMAKE_HOST_SYSTEM_NAME:..................: Windows
    CMAKE_BUILD_TYPE:........................: Release
    CMAKE_CXX_COMPILER_ARCHITECTURE_ID:......: x64
    CMAKE_CXX_STANDARD:......................: 20
    CMAKE_CXX_COMPILER_VERSION:..............: 19.41.34120.0
    CMAKE_CXX_SIZEOF_DATA_PTR:...............: 8
    CMAKE_GENERATOR:.........................: Ninja
    CMAKE_VERSION:...........................: 3.30.5
    CMAKE_MINIMUM_REQUIRED_VERSION:..........: 3.20
    VCPKG_TARGET_TRIPLET.....................: 
    CMAKE_DEBUG_POSTFIX......................: 
    system_bits..............................: 64
    GDEXTENSION_LIB_NAME.....................: orchestrator.windows.64.release
    RESOLVED_VERSION.........................: 2.2.0
    GIT_COMMIT_HASH..........................: 5a7a5e44c0046e2225af98462731ef2ae24d5db3
    GODOT_CPP_GIT_COMMIT_HASH................: dfc51960f9563c6df39a1a0ab66350374f932897

CMake Paths
    CMAKE_CURRENT_SOURCE_DIR.................: E:/GitHub/godot-orchestrator
    CMAKE_TOOLCHAIN_FILE:....................: 
    CMAKE_SOURCE_DIR:........................: E:/GitHub/godot-orchestrator
    CMAKE_COMMAND:...........................: E:/Jetbrains/CLion/bin/cmake/win/x64/bin/cmake.exe
    CLANG_FORMAT_PROGRAM:....................: 
    SCONS_PROGRAM:...........................: E:/Python/Python312/Scripts/scons.exe
    CMAKE_CXX_COMPILER:......................: E:/VisualStudio/VC/Tools/MSVC/14.41.34120/bin/Hostx64/x64/cl.exe
    CMAKE_CXX_FLAGS..........................: /DWIN32 /D_WINDOWS /EHsc
    CMAKE_LINKER:............................: E:/VisualStudio/VC/Tools/MSVC/14.41.34120/bin/Hostx64/x64/link.exe
    CMAKE_EXE_LINKER_FLAGS...................: /machine:x64
    CMAKE_BUILD_TOOL:........................: E:/Jetbrains/CLion/bin/ninja/win/x64/ninja.exe
    vcpkg_executable:........................: 
    godot_debug_editor_executable:...........: E:/GitHub/godot-orchestrator/extern/godot-engine/bin/godot.windows.editor.dev.x86_64.exe
    CMAKE_INSTALL_PREFIX:....................: C:/Program Files (x86)/orchestrator
    CMAKE_BINARY_DIR:........................: E:/GitHub/godot-orchestrator/cmake-build-release
    GDEXTENSION_LIB_PATH:....................: E:/GitHub/godot-orchestrator/project/addons/orchestrator

This creates a conflict between the godot-cpp and parent project based on flags such as /MD and /MT, too. Is there a specific reason why template_debug is used or a way to influence this?

UPDATE: I've also tried building against the latest master commit 3c55ca7a14cffbda60d1d587c965c5a09d02505d and I observe exactly the same behavior.

Steps to reproduce

Just building my plug-in Orchestrator that worked fine prior to the CMake modernization changes.

Minimal reproduction project

N/A

[Naros]

Gentle ping to @enetheru who introduced these changes.
Any input/suggestions because this is blocking our migration to 4.4.

[enetheru]

I'll respond as soon as I can :) Thanks for reaching out.

[enetheru]

OK so to start with, there is a conflation between godot's debug_features, and a Debug build.
When making a template_debug build, what we are doing is enabling the DEBUG_FEATURES macro which adds a bunch of extra code for debugging within godot engine itself. Which is a separate concept to compiling in debug mode to step through code in a debugger like gdb.

To keep people's 4.3 code compiling, I made the godot::cpp alias point to godot-cpp::template_debug, which is the default build type when building SCons. At the time it seemed the most appropriate, let me know if you think it shouldnt be, perhaps failing might be less confusing.

cmake/godotcpp.cmake:345

    add_library( godot::cpp ALIAS godot-cpp.template_debug )

There are now three separate targets to choose to build against which match the options from SCons:

• godot-cpp.template_release
• godot-cpp.template_debug
• godot-cpp.editor

So in your code, some configurable switch, or a loop to build against these targets would be needed.
The test project uses a loop to build all three

test/CMakeLists.txt:19

foreach( TARGET_ALIAS template_debug template_release editor )
    set( TARGET_NAME "godot-cpp.test.${TARGET_ALIAS}" )
    set( LINK_TARGET "godot-cpp::${TARGET_ALIAS}" )

To summarise: template_debug and template_release are no longer related to CMAKE_BUILD_TYPE as they are conceptually separate things.

This creates a conflict between the godot-cpp and parent project based on flags such as /MD and /MT, too. Is there a specific reason why template_debug is used or a way to influence this?

At the top of the windows.cmake I have detailed the reasoning behind the handling of the CMAKE_MSVC_RUNTIME_LIBRARY option. Can I please have your review on this matter? I have the feeling that my approach might cause more trouble than simply providing documentation to consumers.

[enetheru]

I've got a working orchestrator build at master for godot-cpp and orchestrator, my branch is https://github.com/enetheru/godot-orchestrator/tree/gdext-4.4

[Torets]

there is my pull request, related to that matter hanging there, awaiting workflow approval to run tests =)
It introduces options to hide specific targets, using CMake configuration options.
#1650

[Naros]

I've got a working orchestrator build at master for godot-cpp and orchestrator, my branch is enetheru/godot-orchestrator@gdext-4.4

Thanks @enetheru, I've left two comments on the branch, one related to CMakeLists.txt and the other to the build profile. I think I figured out that the build profile allows you to narrow the godot-cpp sources that are compiled, so you can safely ignore that.

[ghuser404]

@enetheru What is the reason to have all those targets? Especially I don't understand what use the editor target has for godot-cpp.

IIUC, godot compiles with debug symbols with template_debug and without debug symbols with template_release, which already sound like debug/release modes. The only difference is the editor flag, which compiles the editor into the executable. But for the godot-cpp, the editor flag doesn't do that, and is not at all different from the template_debug.

Also, correct me if I'm wrong, we can now compile with these options:
template_debug in Debug mode
template_debug in Release mode
template_release in Debug mode
template_release in Release mode

• So what really happens when we compile template_debug in Release mode or template_release in Debug mode?
• Do we really need template_debug and template_release on top of Debug and Release modes?
• Why do we need editor target?

[enetheru]

I'm ging to have to make some template answer for this at some point that I can copy paste I've explained it so many times.

editor, template_debug and template_release are an abstraction layer up from Debug and Release. Debug/Release or dev_build=yes are for engine developers. editor, template_debug, template_release are for engine users.

• So what really happens when we compile template_debug in Release mode or template_release in Debug mode?
  You do, or do not get Debug Symbols and optimisations for those builds, like normal.

• Do we really need template_debug and template_release on top of Debug and Release modes?
  Yes, they address different abstraction layers so they do need to be separate.

• Why do we need editor target?
  For editor plugins, you might not want to publish your game with all the tools used to build it compiled into your binary.

This is all a reflection of the SCons build system target and how it effects godot-cpp.

[enetheru]

that abstraction explanation is poor let me try again.. holdup.

[enetheru]

Ignoring gdextension, addons are split into three categories, editor, template_release, template_debug.

'editor' for game developers creating games, 'template_release' for the final product, and 'template_debug' for when you want to debug the final product, or hand players debug versions to test with and report back with info without handing them editor tools.

None of these have Debug Symbols, as they only rely on the editor, and gdscript. If you wanted Debug Symbols you would likely be working on the editor itself, and so I would categorise you as an engine developer, rather than a game developer.

gdextension is general purpose, so you might be developing editor tools only that dont need to be distributed to players, or a plugin that can be used by game developers to then create, and distribute to players, or the whole game itself.

As a result gdextensions ends up in the same situation as the editor, with the same requirements.

[ghuser404]

@enetheru That makes a lot of sense! Thank you for the write up. I've dug quite a bit into this topic myself, and the picture is a lot clearer now. The template_debug defines DEBUG_ENABLED, so that we can enable logging or whatever, but that doesn't mean we include C++ debug symbols, which would allow us to step through the code.

One thing caught me off guard though, is that here it says target=template_debug: Build with C++ debugging symbols. Maybe it meant to say with debugging code as mentioned above for the target=editor?
https://docs.godotengine.org/en/stable/contributing/development/compiling/introduction_to_the_buildsystem.html#target

[enetheru]

One thing caught me off guard though, is that here it says target=template_debug: Build with C++ debugging symbols

Good spotting, I read through the SCons code to see. Looks like the docs are wrong, so I left a comment at the bottom for document writers.

I certainly got caught out in the same trap when I started looking into this a year or so ago, took me a while to grok the difference in abstraction. And I've talked about it at least a dozen times in discord, and now here too. Such a waste of everyone's time from so small a thing.

[enetheru]

@Naros can this be closed?

[Naros]

It can, closing as its obsolete.