godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.12k stars 69 forks source link

Use different build executables for multiple run instances #10231

Open warent opened 2 months ago

warent commented 2 months ago

Describe the project you are working on

A C# game with a client and a dedicated server

Describe the problem or limitation you are having in your project

The dedicated server wants to have its own directives different from the client (e.g. GODOT_SERVER) to alter code at compile time. Currently, all run instances have the same builds

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Every run instance can optionally have its own build / executable

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Everything works the same as before, but the codebase intelligently detects if the user wishes to specify different build time arguments (for example: https://github.com/godotengine/godot-proposals/issues/10028), and if so, then it will instead create a unique build for every unique run instance.

Unfortuantely the changes to make this work would probably be extensive. In my mind, it would work something like the following:

  1. Any buildInfo: BuildInfo needs to start being treated as an array like buildInfos: BuildInfo[]
  2. Hence, CreateBuilldInfo becomes private static BuildInfo[] CreateBuildInfo, and it would need to call RunInstancesDialog::get_singleton()->get_instance_count(); to create a unique build info object for every run instance.
  3. LaunchBuild then accepts this array, and for each of those buildInfo objects, it runs any mutating functions like BuildArguments
  4. As a final step, LaunchBuild would somehow compare each of those BuildInfo objects and replace duplicates with references to the same BuildInfo, ensuring that duplicates are not rebuilt, and those run instances share the same executable

Somewhere along the way, I think Editor::Run needs to be updated because String exec = OS::get_singleton()->get_executable_path(); would no longer work, as there would be multiple executables.

If this enhancement will not be used often, can it be worked around with a few lines of script?

For my very specific case it can be worked around using OS.HasFeature("dedicated_server") although it is far from ideal. There is no way to workaround generally adding custom directives and/or args per build

Is there a reason why this should be core and not an add-on in the asset library?

Core engine

Calinou commented 2 months ago

There seems to be two proposals in one here:

  1. Allowing a project run to use an editor/export template binary that is different from the editor binary that is used to edit the project. This can already be achieved with one-click deploy using custom export templates, but not when running from the editor without going through the one-click deploy process (which is slower and always creates a PCK file in a temporary location).
  2. Passing preprocessor defines for the C# build on a per-instance basis, resulting in multiple DLLs being built. The engine binaries here don't actually need to be different though, only the C# libraries.

I suggest implementing one at a time as the features can be used independently from each other. The second one is also only useful in the context of C#, not GDScript.

warent commented 2 months ago

The engine binaries here don't actually need to be different though, only the C# libraries.

Ah, I see, that's a piece I was missing. I might be able to help implement a draft PR for this if someone can provide pointers of which parts in the code would need to be altered. I'm also unsure how architectural decisions are made. Is that something I would coordinate in the new Discord?

Calinou commented 2 months ago

I'm also unsure how architectural decisions are made. Is that something I would coordinate in the new Discord?

Engine development happens on the Godot Contributors Chat. We don't use Discord for engine development discussions.