C#: Move marshaling logic and generated glue to C#

We will be progressively moving most code to C#.
The plan is to only use Mono's embedding APIs to set things at launch.
This will make it much easier to later support CoreCLR too which
doesn't have rich embedding APIs.

Additionally the code in C# is more maintainable and makes it easier
to implement new features, e.g.: runtime codegen which we could use to
avoid using reflection for marshaling everytime a field, property or
method is accessed.

SOME NOTES ON INTEROP

We make the same assumptions as GDNative about the size of the Godot
structures we use. We take it a bit further by also assuming the layout
of fields in some cases, which is riskier but let's us squeeze out some
performance by avoiding unnecessary managed to native calls.

Code that deals with native structs is less safe than before as there's
no RAII and copy constructors in C#. It's like using the GDNative C API
directly. One has to take special care to free values they own.
Perhaps we could use roslyn analyzers to check this, but I don't know
any that uses attributes to determine what's owned or borrowed.

As to why we maily use pointers for native structs instead of ref/out:
- AFAIK (and confirmed with a benchmark) ref/out are pinned
  during P/Invoke calls and that has a cost.
- Native struct fields can't be ref/out in the first place.
- A `using` local can't be passed as ref/out, only `in`. Calling a
  method or property on an `in` value makes a silent copy, so we want
  to avoid `in`.

REGARDING THE BUILD SYSTEM

There's no longer a `mono_glue=yes/no` SCons options. We no longer
need to build with `mono_glue=no`, generate the glue and then build
again with `mono_glue=yes`. We build only once and generate the glue
(which is in C# now).
However, SCons no longer builds the C# projects for us. Instead one
must run `build_assemblies.py`, e.g.:
```sh
%godot_src_root%/modules/mono/build_scripts/build_assemblies.py \
        --godot-output-dir=%godot_src_root%/bin \
        --godot-target=release_debug`
```
We could turn this into a custom build target, but I don't know how
to do that with SCons (it's possible with Meson).

OTHER NOTES

Most of the moved code doesn't follow the C# naming convention and
still has the word Mono in the names despite no longer dealing with
Mono's embedding APIs. This is just temporary while transitioning,
to make it easier to understand what was moved where.

1 files changed, 0 insertions, 31 deletions

diff --git a/modules/mono/SCsub b/modules/mono/SCsub
index d10ebc7b47..5757917f56 100644
--- a/modules/mono/SCsub
+++ b/modules/mono/SCsub
@@ -7,21 +7,6 @@ Import("env_modules")
 
 env_mono = env_modules.Clone()
 
-if env_mono["tools"]:
-    # NOTE: It is safe to generate this file here, since this is still executed serially
-    import build_scripts.gen_cs_glue_version as gen_cs_glue_version
-
-    gen_cs_glue_version.generate_header("glue/GodotSharp", "glue/cs_glue_version.gen.h")
-
-# Glue sources
-if env_mono["mono_glue"]:
-    env_mono.Append(CPPDEFINES=["MONO_GLUE_ENABLED"])
-
-    import os.path
-
-    if not os.path.isfile("glue/mono_glue.gen.cpp"):
-        raise RuntimeError("Mono glue sources not found. Did you forget to run '--generate-mono-glue'?")
-
 if env_mono["tools"] or env_mono["target"] != "release":
     env_mono.Append(CPPDEFINES=["GD_MONO_HOT_RELOAD"])
 
@@ -29,22 +14,6 @@ if env_mono["tools"] or env_mono["target"] != "release":
 
 mono_configure.configure(env, env_mono)
 
-if env_mono["tools"] and env_mono["mono_glue"] and env_mono["build_cil"]:
-    # Build Godot API solution
-    import build_scripts.api_solution_build as api_solution_build
-
-    api_sln_cmd = api_solution_build.build(env_mono)
-
-    # Build GodotTools
-    import build_scripts.godot_tools_build as godot_tools_build
-
-    godot_tools_build.build(env_mono, api_sln_cmd)
-
-    # Build Godot.NET.Sdk
-    import build_scripts.godot_net_sdk_build as godot_net_sdk_build
-
-    godot_net_sdk_build.build(env_mono)
-
 # Add sources
 
 env_mono.add_source_files(env.modules_sources, "*.cpp")