Explain the reason of an editor build target #1934

Activity

1. enetheru commented on Feb 23, 2026

   

   enetheru

   on Feb 23, 2026

   Collaborator

   More actions

   The build system is largely copied from Godot(scons) and CMake mirrors the features.
   The distinction may be superfluous from the perspective of godot-cpp itself, but it's not entirely for plugin developers who want to gate features specifically behind the tools enabled flags.

   @dsnopek will know more i'm sure.
2. dsnopek commented on Feb 23, 2026

   

   dsnopek

   on Feb 23, 2026

   Last edited by dsnopek

   Collaborator

   More actions

   Yeah, it's for GDExtension developers, if they want to make editor-only builds. It uses the define TOOLS_ENABLED because that's the same as in Godot modules. Most extensions don't need editor-only builds, though, having debug and release builds (where the "debug" one is used in the editor) is usually sufficient.
3. YakoYakoYokuYoku commented on Feb 23, 2026

   

   YakoYakoYokuYoku

   on Feb 23, 2026

   Author

   More actions

   Yeah, it's for GDExtension developers, if they want to make editor-only builds. It uses the define TOOLS_ENABLED because that's the same as in Godot modules. Most extensions don't need editor-only builds, though, having debug and release builds (where the "debug" one is used in the editor) is usually sufficient.

   Then an editor only build is only different to a debug build by just a preprocessor argument not used in godot-cpp code, not even in the generated sources. Wouldn't be better to make the editor target depend on debug and make it an interface library? That way we avoid having to build the binding code again for editor only plugins.
4. enetheru commented on Feb 24, 2026

   

   enetheru

   on Feb 24, 2026

   Collaborator

   More actions

   That way we avoid having to build the binding code again for editor only plugins.

   Why would this be a problem? under what circumstance does it trigger difficulty?
5. dsnopek commented on Feb 24, 2026

   

   dsnopek

   on Feb 24, 2026

   Collaborator

   More actions

   Wouldn't be better to make the editor target depend on debug and make it an interface library? That way we avoid having to build the binding code again for editor only plugins.

   I'm also not sure what you mean. But, ultimately, in your extension you can make your builds however you want!

   We have these 3 types built-in (editor, template_debug, and template_release), but you can make fewer builds, or even more builds that target other Godot feature tags.

   The "editor" build and TOOLS_ENABLED macro provide parity with Godot modules, which use that macro to only build certain functionality for the editor. So, it's a natural fit for an extension that can also be compiled as a module. But no extension is required to use it.
6. YakoYakoYokuYoku commented on Feb 25, 2026

   

   YakoYakoYokuYoku

   on Feb 25, 2026

   Author

   More actions

   Why would this be a problem? Under what circumstance does it trigger a difficulty?

   When packaging godot-cpp for a Linux distribution, I desire to offer the package with static libraries for both debug and release plus a way for users wishing to compile editor plugins.

   The "editor" build and TOOLS_ENABLED macro provide parity with Godot modules, which use that macro to only build certain functionality for the editor. So, it's a natural fit for an extension that can also be compiled as a module. But no extension is required to use it.

   I know, but I don't think that such build by itself is justified considering that there's no godot-cpp code change and that TOOLS_ENABLED is somewhat equivalent to the Engine.is_editor_hint() method in GDScript. My proposal would be to implement the editor target in fashion of a CMake interface library.

   # No need to depend on any source directly
   add_library(godot-cpp-editor INTERFACE)
   
   # Wrap the bindings library
   target_link_libraries(godot-cpp-editor INTERFACE godot-cpp)
   
   # With this anything that links godot-cpp-editor will pass TOOLS_ENABLED
   target_compile_definitions(godot-cpp-editor INTERFACE TOOLS_ENABLED)
   
   # ...
   
   # Link the editor interface library
   target_link_libraries(example PRIVATE godot-cpp-editor)
7. enetheru commented on Feb 25, 2026

   

   enetheru

   on Feb 25, 2026

   Collaborator

   More actions

   When packaging godot-cpp for a Linux distribution

   As I suspected. Please don't. Source packages only please.

   godot-cpp is not intended to be pre-compiled as a library for wide distribution.

   It is designed to be tailored to specific projects, and incorporated into the build process itself.
   It is not designed for use as a stable widely distributed library.

   So your efforts to package it will in-fact confuse developers attempting to create plugins, and in turn add to issue trackers configurations that nobody supports.

   👍React with 👍2Reacted by David Snopek and sash-rc