Allow compiling the editor with minimal features

[Goldenlion5648]

Problem or limitation

Compiling the editor for making PRs takes between 4-6 minutes on my machine on fresh a branch, and between 20-40 seconds on following builds if 1-2 files has changed.

It would be nice if the initial time was shorter. If I am making a simple change to settings or the text editor, do I really need to compile all these that are blacklisted from disabling in the scons file?

        "disable_3d",
        "disable_advanced_gui",
        "disable_physics_2d",
        "disable_physics_3d",
        "disable_navigation_2d",
        "disable_navigation_3d",

I tried to be clever and use a cache path that was outside of where I cloned into, so that different worktrees could use it, but the file location of each file is taken into account, so debugging doesn't work correctly

My current args are these

                "dev_build=yes",
                "cache_path=~/Documents/programming/prs/godot_compile_cache",
                "linker=mold",
                
                "ninja=no",
                "object_prefix=no_ninja",
                "disable_xr=yes",
                "module_jolt_physics_enabled=no",
                "builtin_embree=no",
                "builtin_freetype=no",
                "builtin_graphite=no",
                "builtin_harfbuzz=no",
                "builtin_libogg=no",
                "builtin_libpng=no",
                "builtin_libtheora=no",
                "builtin_libvorbis=no",
                "builtin_libwebp=no",
                "builtin_mbedtls=no",
                "builtin_miniupnpc=no",
                "builtin_pcre2=no",
                "builtin_sdl=no",
                "builtin_zlib=no",
                "builtin_zstd=no",
                "scu_limit=10000",

Proposed improvement

allow disabling many of the "extra" features that are currently blacklisted, and/or add a "minimal" option to scons to allow only compiling the bare minimum

Proposal review

• Yes, this proposal is highly specific and actionable.

[AThousandShips]

disable_advanced_gui will not be possible to disable with the editor, it depends on things like Tree

[AThousandShips]

This would involve a lot of extra and fragile checks and things in the editor, see:

• Allow building the editor with 3D disabled, or without 3D Physics/Navigation. godot#105579

That alone involves a lot of ad-hoc code to disable it

[Goldenlion5648]

I see what you mean by a lot of fragile checks.

Is there a trick of some kind that the maintainers use to test out so many PRs? Just fast hardware so build times are not too long? Or am I missing something that really speeds up iteration with many unrelated PRs?

[Calinou]

Is there a trick of some kind that the maintainers use to test out so many PRs? Just fast hardware so build times are not too long?

Yes, having fast hardware and SCons parameters tailored for build speed (scu_build=all linker=mold optimize=none fast_unsafe=yes) is the main way to speed up compilation. That said, you can speed up the overall PR testing process by having a script that handles checking out a branch, rebasing on top of master when possible and creating a blank project (or downloading an existing project and importing it). I wrote https://gist.github.com/Calinou/9509da17ee3f3773ac6b47e5c2713c5e which can work on Linux on macOS.

You can also use the precompiled CI builds on each PR's Checks tab, so you don't have to compile anything. See Testing pull requests for more information.

[AThousandShips]

I see what you mean by a lot of fragile checks.

What I mean is that we have to add a bunch of if(n)def things and control individual files for compilation, see for example recent bugs with missing includes and compile issues when changing includes etc.:

• Fix build regression for Linux template_release godot#117319
• [Debugger] Fix 3D disabled builds godot#117255
• Fix tile_set.h not including ArrayMesh godot#117156

These are all caused by conditional compile things and that would likely be far more tricky in editor code to get right and not break in specific edge cases when changing some include etc., the scene/debugger folder is especially vulnerable to this, the editor would be more so

Since most people won't build the specific variants it could be weeks until it's discovered, or worse, adding a lot of potential debt in fixing it, making it hard to do so

[WhalesState]

I agree, Also disabling 3D support can be beneficial for developers primarily working on GUI or 2D workflows, as it reduces build and link times.

[Naros]

Also disabling 3D support can be beneficial for developers primarily working on GUI or 2D workflows

Unless the Godot team intends to ship runtime templates that specifically target only 2D/GUI applications without 3D support, this is something I would fully expect to be maintained in one's fork. For all the reasons that have already been given, it makes little sense for this to be in the upstream Godot project if there is no intent for such binary distributions from the team itself.