Refactor build object suffix to standardized tuples/target triples identifying build options

[Calinou]

Credits to @akien-mga in godotengine/godot#24030 for the original issue text. I reopened it as a proposal so it gets more visibility here.

Describe the project you are working on:

The Godot editor 🙂

Describe the problem or limitation you are having in your project:

We currently set a suffix string in SConstruct that is appended to the name of all build objects, and most importantly the final Godot binary. It contains some information about the build options (platform, target, tools, ~arch/bitness, ~compiler), but not in a very consistent way for all platforms: most don't include compiler info, some have arch info, others have bitness info, the use of tools impact what kind of target info is included, etc.

The current form is more or less:

godot.<platform>.<target and/or tools>.<bits or arch>[.<module suffix>][.<compiler>][.<user-defined extra suffix>][<extension>]

(order might differ a bit towards the tail, didn't double check)

So we typically get binary names like these:

godot.windows.opt.tools.64.mono.exe
godot.x11.opt.debug.32.llvm

(Some other platforms don't follow this scheme and have instead:

platform/android/java/libs/debug/armeabi-v7a/libgodot_android.so

and a resulting bin/android_debug.apk bundling the libs for all built arches.
Their intermediate build options however follow the scheme:

core_bind.android.debug.armv7.neon.o

albeit with some variation (see e.g. .neon here))

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

I propose to refactor this system to use well-documented and standardized tuples, so that you can see at a glance how a binary was configured. Such information could also be included in godot --version and printed to stdout on start, so that we get reliable info on users' build in bug reports.

It would then also be easier for thirdparty buildsystems (e.g. GDNative plugins) to use compatible tuples, especially if we factor out this SCons logic in a Python module that could be reused outside Godot.

This should also be the opportunity to sanitize the mess we currently have with arch, android_arch and bits options. We should only use arch and drop the rest IMO. (If we want to keep bits for convenience, its mapping to "common-sense" arches -- e.g. arch=x86_64 for bits=64 on PC) for the given platform should likely be done in a module in a big switch, to avoid polluting each platform's detect.py)

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

I don't have a proposal yet for how it should look like exactly, so feel free to do some research on what other projects do and make suggestions. Some data:

• Rust target triples: https://forge.rust-lang.org/platform-support.html
• Debian multiarch tuples: https://wiki.debian.org/Multiarch/Tuples

Information that should be included by our target tuple (won't be a triplet as we need more than 3 fields):

• platform (currently x11, windows, android, etc.)
• target (currently opt, opt.debug, debug)
• architecture (currently a mess mixing bits, arch and android_arch based on the target platform)
• tools (currently tools or nothing)
• compiler (currently only llvm exists, but we should have gcc, llvm, msvc, etc.)
• noteworthy build options (currently only mono, defined with env.add_module_version_string). We can't document every single build option this way though, so it should be limited to those which really matter for everyday use, like whether the build is linked againt the Mono SDK or not

The extra_suffix may not need to be included in the tuple and could just be appended at the end.

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

No, as this is core build system functionality.

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

This is core build system functionality.

[Xrayez]

Pretty please, lets add no_suffix option: godotengine/godot#24030 (comment). I don't really care about all those suffixes at the end of the day as long as I can compile, properly configure IDE for development without having to guess what kind of suffix to encode, especially the existence of different host platforms (perhaps just include the platform name in the binary, that's all), this suggestion also stems from godotengine/godot#37248.

You have to recompile the entire engine each time the more diversity we add to the resulting suffix name. Having no suffix could improve compilation times if you do have to change the configuration often, without producing a different binary for each. Again, this would only promote faster development iterations.

[aaronfranke]

If we want to keep bits for convenience, its mapping to "common-sense" arches -- e.g. arch=x86_64 for bits=64 on PC

For compile options for Godot, I don't think it's worth keeping bits. We already have bits=64 by default, and most systems are 64-bit these days, so if people wanted 32-bit x86 it would cause little inconvenience to require arch=x86_32 instead of bits=32 (adding _32 to avoid confusion if people accidentally wanted 64-bit x86, or we can just do arch=x86).

For in-Godot uses, it would be nice if the OS feature flags for 32 and 64 were changed from being x86-specific to just being 32-bit or 64-bit in general. Maybe they should also be renamed to 64-bit or 64bit or similar.

[akien-mga]

Proposal #3371 covers how the tools and target options could be refactored to be more user-friendly and self-documenting. This is somewhat related/a subset of this proposal.

[dmoody256]

Also I would suggest not using [LIB|PROG|OBJ]SUFFIX var for the triple. This is really the systems standard suffixes. You should instead just append the suffix to the file via a custom environment variable in the custom add_ functions, or make custom Psuedobuilders. The only caveat is if referring to one of those output files by raw string, you will need to append the custom SUFFIX var in the raw string, e.g, env.Command(some_output, 'raw/string/example_module_lib${GODOT_SUFFIX}', some_action), however throughout the godot build, libs, objs, and programs are only referenced by File objects, so there is nothing impacted by the caveat currently.