Previously, all of the code generation routines would just needlessly
write the same files over and over, even when not needed.
This became a problem with the advent of the experimental ninja backend
for SCons, which can be trivially enabled with a few lines of code and
relies on timestamp changes, making it thus impractical.
VS doesn't handle string parsing very well, so having all the files in one
property slows down VS a lot when loading the projects. Splitting the files
up into per-directory properties brings down project processing times from
20 seconds to 1 second (on my machine).
This can be used to quickly see how recent a development build is,
without having to look up the commit date manually.
When juggling around with various builds (e.g. for benchmarking),
this can also be used to ensure that you're actually running the
binary you intended to run.
The date stored is the date of the Git commit that is built, not
the current date at the time of building the binary. This ensures
binaries can remain reproducible.
The version timestamp can be accessed using the `timestamp` key
of the `Engine.get_version_info()` return value.
Users can add additional VS project configurations with their own
custom settings, but to support this workflow, we can't rely directly
on $(Platform) and $(Configuration), because VS needs those to be
both unique Configuration|Platform combos, and we need to allow for
different combos of Configuration|Platform to point to the same
scons build configuration.
GodotPlatform and GodotConfiguration properties lets us decouple from
the magic VS properties that we don't control, so users can add
however many Platform|Configuration combos they want and still
point to a specific GodotPlatform|GodotConfiguration build config.
Custom Visual Studio project generation logic that supports any platform that has a msvs.py
script, so Visual Studio can be used to run scons for any platform, with the right defines per target.
Invoked with `scons vsproj=yes`
To generate build configuration files for all platforms+targets+arch combinations, users should call
```
scons vsproj=yes platform=XXX target=YYY [other build flags]
```
for each combination of platform+target[+arch]. This will generate the relevant vs project files but
skip the build process, so that project files can be quickly generated without waiting for a command line
build. This lets project files be quickly generated even if there are build errors.
All possible combinations of platform+target are created in the solution file by default, but they
won't do anything until each one is set up with a scons vsproj=yes command for the respective platform
in the appropriate command line. This lets users only generate the combinations they need, and VS
won't have to parse settings for other combos.
Only platforms that opt in to vs proj generation by having a msvs.py file in the platform folder are included.
Platforms with a msvs.py file will be added to the solution, but only the current active platform+target+arch
will have a build configuration generated, because we only know what the right defines/includes/flags/etc are
on the active build target currently being processed by scons.
Platforms that don't support an editor target will have a dummy editor target that won't do anything on build,
but will have the files and configuration for the windows editor target.
To generate AND build from the command line, run
```
scons vsproj=yes vsproj_gen_only=no
```
Verbose output is meant for debugging the SCU mode itself and can be
triggered by changing the `_verbose` bool manually.
Prefix all prints with "SCU:" for context, and print the processed
folders all at once instead of when adding the sources.
This fixes multiple issues/inconsistencies around `get_compiler_version()`:
* With no shell allocated, launching the compiler could fail even
with proper paths being set.
* The return value was described as "an array of version numbers as ints",
but the function actually returned a `Dictionary` (or `None`).
* Not all calls were properly handling a `None` return value in case of errors.
On Windows this broke compiling for me since #81869 with default settings.
* Some calls defined inconsistent defaults/fallbacks (`0` or `-1`).
Even if you specify the subsystem to be the console one, the vsproj doesn't carry over the setting, which makes working with this mode in the IDE a bit annoying since it'll regenerate the vsproj right afterwards. Since there's only two options and 'gui' is the default, we only carry over the 'console' setting.
Follow-up to #75932.
Since these icons are only used by the export plugin, it makes sense to
move them and generate the headers there.
The whole `detect.is_active()` logic seems to be a leftover from before
times, as far back as 1.0-stable it already wasn't used for anything.
So I'm removing it and moving the export icon generation to
`platform_methods`, where it makes more sense.
Ensures that the versions always match the Godot version, albeit following
SemVer 2.0 so inserting a dot between "beta" and the build number.
For "stable" status, we omit the suffix as this would be interpreted as a
pre-release build too.
So we have:
| Godot version | Nupkg version |
| -------------- | -------------- |
| 4.0.0-beta | 4.0.0-beta |
| 4.0.0-beta2 | 4.0.0-beta.2 |
| 4.0.0-rc1 | 4.0.0-rc.1 |
| 4.0.0-stable | 4.0.0 |
This adds support for building solutions with dev_mode and/or float=64 enabled.
Additionally, it adds solution generation to the Windows CI to catch future regressions.
Implements https://github.com/godotengine/godot-proposals/issues/3371.
New `target` presets
====================
The `tools` option is removed and `target` changes to use three new presets,
which match the builds users are familiar with. These targets control the
default optimization level and enable editor-specific and debugging code:
- `editor`: Replaces `tools=yes target=release_debug`.
* Defines: `TOOLS_ENABLED`, `DEBUG_ENABLED`, `-O2`/`/O2`
- `template_debug`: Replaces `tools=no target=release_debug`.
* Defines: `DEBUG_ENABLED`, `-O2`/`/O2`
- `template_release`: Replaces `tools=no target=release`.
* Defines: `-O3`/`/O2`
New `dev_build` option
======================
The previous `target=debug` is now replaced by a separate `dev_build=yes`
option, which can be used in combination with either of the three targets,
and changes the following:
- `dev_build`: Defines `DEV_ENABLED`, disables optimization (`-O0`/`/0d`),
enables generating debug symbols, does not define `NDEBUG` so `assert()`
works in thirdparty libraries, adds a `.dev` suffix to the binary name.
Note: Unlike previously, `dev_build` defaults to off so that users who
compile Godot from source get an optimized and small build by default.
Engine contributors should now set `dev_build=yes` in their build scripts or
IDE configuration manually.
Changed binary names
====================
The name of generated binaries and object files are changed too, to follow
this format:
`godot.<platform>.<target>[.dev][.double].<arch>[.<extra_suffix>][.<ext>]`
For example:
- `godot.linuxbsd.editor.dev.arm64`
- `godot.windows.template_release.double.x86_64.mono.exe`
Be sure to update your links/scripts/IDE config accordingly.
More flexible `optimize` and `debug_symbols` options
====================================================
The optimization level and whether to generate debug symbols can be further
specified with the `optimize` and `debug_symbols` options. So the default
values listed above for the various `target` and `dev_build` combinations
are indicative and can be replaced when compiling, e.g.:
`scons p=linuxbsd target=template_debug dev_build=yes optimize=debug`
will make a "debug" export template with dev-only code enabled, `-Og`
optimization level for GCC/Clang, and debug symbols. Perfect for debugging
complex crashes at runtime in an exported project.
This makes it possible to retrieve all relevant versioning info used to
generate `core/version_generated.gen.h` in the buildsystem.
Notably it makes the custom logic parsing the `GODOT_VERSION_STATUS`
environment variable to override status easy to reuse.
We want to replace libnethost as it gives us issues with some compilers.
Our implementation tries to mimic libnethost's hostfxr_resolver search
logic. We try to use the same function names for easier comparing in
case we need to update this in the future.
