Lukas Tenbrink

Making this a draft while I figure out current issues with the build, while striving to keep godot-cpp-template simple.

Aside: Getting to this point took a bit, because i had to figure out what the intended build arguments in `godot-cpp` were intended for, specifically `target` (debug vs release) and...

Oh, that's good! Then i suppose all that this proposal really needs is two PRs to change the default (godot-cpp-template) and recommended (docs) ways of doing this. If we agree...

Closing because what @dsnopek said is totally right. We may want to document this better, but it is already possible to use a single binary for both debug and release.

> * `call(method: StringName, ...) varargs` In my opinion, `...` without a name to the varargs should be avoided, because it may be unclear what the additionally supplied arguments will...

> The Milestone says 4.4, is this still planned for 4.4? Nope, the window for new features was closed with the 4.4 beta. The milestone just hasn't been updated yet.

~~This is half addressed in #55, through the use of `env["suffix"]` in the naming scheme, which is [defined here](https://github.com/godotengine/godot-cpp/blob/253e095c815158184c9ec044fd0699d93c68675d/tools/godotcpp.py#L495) and (i think) intended for this purpose. The PR does not...

> Secondly `libEXTENSION-NAME.macos.template_debug` is missing env["arch"] That one _is_ actually fixed by #55.

I forgot about this issue - the [`.gdextension`](https://github.com/godotengine/godot-cpp-template/blob/main/demo/bin/example.gdextension) file has had `double` entries since https://github.com/godotengine/godot-cpp-template/pull/85 was merged.

An alternative would be to _not_ default to `light`: When no theme is passed (`undefined`), just don't call `setTheme`. I wouldn't do this because it still implies the wrong mindset...