Remove .dev suffix from builds.

[Ivorforce]

I know this is going to be controversial, but it's a simple PR, so I want to just put it out there. I'm not 100% we should merge this, myself.

I have pre-written some thoughts against this change below, and my thoughts for them.
They are a bit ramble-y, so feel free to partake in the discussion freely without acknowledging them 😅

Reasoning

Currently, godot-cpp automatically adds the .dev suffix to builds that are created with the dev_build=yes flag.
This can result in binaries named like so:

libgdexample.linux.template_release.dev.x86_32.so  ; For dev_build=yes
libgdexample.linux.template_release.x86_32.so  ; For dev_build=no (default)

The .gdextension file needs to choose one of these formats to load from:

linux.release.x86_32 = "res://bin/libgdexample.linux.template_release.x86_32.so"
; Or:
linux.release.x86_32 = "res://bin/libgdexample.linux.template_release.dev.x86_32.so"

It cannot choose 'either': One of the two must be chosen.

In a normal dev cycle, one may default to building with dev_build=yes to get faster builds for testing. Therefore, one may choose the .dev entry for the demo project.
However, when it comes to testing the project's release-ready binary, one must either test it in a different project, or edit the .gdextension file to load the non- .dev binary temporarily, or rename the binary to .dev by hand.

This is not only tedious, but actually confusing: I've seen a few people in Discord help channels run into problems because they built the version that wasn't loaded by the editor, and wondered why the GDExtension wouldn't respond to code changes. I have also run into this problem, and proceeded to [strip .dev from my own dev versions in SConstruct.

In defense of .dev

.dev is used for .dev binaries by Godot itself. godot-cpp tries to emulate godot upstream behavior as much as possible, to reduce complexity across the projects. However, Godot does not have the problems described above, as the binary is not added to a .gdextension file. I think it makes sense for Godot, but less for godot-cpp.

.dev denotes a compatibility change, like the other suffixes. .dev includes debug symbols, and can therefore do things regular builds cannot. However, this does not concern Godot itself. For godot, it does not matter whether the binary is built with debug symbols or not. Therefore, I do not think this argument holds.

.dev protects against confusing it for an optimized build. dev builds are unoptimized, so uploading one would be a mistake. .dev suffixes protect against accidentally uploading the wrong version. I don't have any contra for this argument, it should be weighed against benefits. We could add other protections too, such as a warning when dev libraries are loaded into Godot.

.dev can still be optimized, using explicit build args. If one builds with scons dev_build=yes lto=auto optimize=speed, the resulting binary will be optimized very similar to an actual build. This may be good enough for testing performance. This is a valid workflow, and if we reject this PR, it should be documented.

Compiling dev builds with .dev saves time when switching between the two. This is correct, and arguably, we should keep .dev suffixes for object files to preserve this. However, preserving the final binary saves at most the LTO step, I think.

Alternative Solution

Instead of stripping the .dev suffix, it would be possible to auto-generate a .gdextension file with a SCons tool. The entry would always load the latest build in Godot, no matter the configuration. This would allow the binaries to keep their current name, and the above confusion to still be resolved.
However, this would require making the tool, and .gdextension files would not be written by hand anymore. Instead, the tool would need to cover its whole range of features.

It is also possible for users that want to adopt this workflow to just strip .dev suffixes from the binary like I did. This could be documented to give users freedom of choice.

[Naros]

It is also possible for users that want to adopt this workflow to just strip .dev suffixes from the binary like I did. This could be documented to give users freedom of choice.

Would it make sense to conditionalize this behavior for those who prefer to keep the designation?

[Ivorforce]

Would it make sense to conditionalize this behavior for those who prefer to keep the designation?

You mean of my original proposal, or the part you quoted?
Either way the final choice is with the godot-cpp user, because they can strip or add .dev at will in their SConstruct. This discussion is more about which is the saner default.

[dsnopek]

I'm not opposed to removing the .dev suffix.

This is something that folks have complained about for a long time, and it doesn't really provide a ton of value - I think it makes much more sense for an executable (like Godot) than a library.

[enetheru]

I have the feeling that this is just covering for inadequacies in the error reporting coming out of godot itself. If the loading code was made to provide clearer errors, and useful information a lot of problems people face would be explained as they attempt to load their project.
We can also improve the examples with additional debug statements in the initialisation so that mistakes are picked up sooner.

I just see the same errors over and over again with loading and a lot of it can be explained by the lack of error reporting and error information coming out of godot.

[Ivorforce]

I have the feeling that this is just covering for inadequacies in the error reporting coming out of godot itself. If the loading code was made to provide clearer errors, and useful information a lot of problems people face would be explained as they attempt to load their project. We can also improve the examples with additional debug statements in the initialisation so that mistakes are picked up sooner.

I just see the same errors over and over again with loading and a lot of it can be explained by the lack of error reporting and error information coming out of godot.

Better error handling would definitely help, but not all problems removing .dev solves are technically errors, I think.