Explain the reason of an editor build target

[YakoYakoYokuYoku]

Godot version

Godot 4.6.1 packaged in Arch Linux

godot-cpp

Version 10.0.0-rc1 albeit this goes with many versions back.

System information

Arch Linux

Issue description

I'm trying to do builds with multiple configurations, debug plus release, with CMake and Ninja. While I was on that I've noticed that there was an editor target which I assume that it's for enabling editor plugins or whatever. The point is that when I've looked up on what selecting it does is nothing besides setting a preprocessor definition named TOOLS_ENABLED which is used nowhere in the source code. I've grepped with and without taking into account .gitignore but it displays no usage of said definition. It might have been used some time ago but it's useless nowadays.

Haven't opened a PR to not jump the gun.

Steps to reproduce

Grep the code for TOOLS_ENABLED or editor or something.

Minimal reproduction project

Just reproduce what I've said in this repo.

[enetheru]

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.

[dsnopek]

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.

[YakoYakoYokuYoku]

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.

[enetheru]

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?

[dsnopek]

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.

[YakoYakoYokuYoku]

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)

[enetheru]

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.