This ensures that the godot-cpp job has plenty of resources
to run its build and avoid being affected by the main build.
Additionally:
- Extract test tasks into dedicated actions.
- Upload artifacts as early as possible.
- Ensure that we check master cache before random cache.
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.
actions/cache@v3
actions/checkout@v3
actions/upload-artifact@v3
actions/setup-dotnet@v2
actions/setup-java@v3
actions/setup-python@v4
mymindstorm/setup-emsdk@v11
Also reset cache keys as we're going to cleanup all caches.
We often hit "Too Many Requests" errors when uploading the cache with
`actions/cache` because there's a limit of 10 GB every 5 minutes, and we can
easily go over it when we amend or merge several PRs in a short timespan.
This will make the CI artifacts less useful for debugging crashes but there's
no real way around this.
This keeps their size small and allows to compare size changes on templates
in PRs, as the template size is what is most relevant to users.
For editor builds we keep debug symbols so they can be used to debug crashes.
Implements exit codes into the engine so tests can return their statuses.
Ideally we don't do this, and we use FIXUP logic to 'begin' and 'end' the engine execution for tests specifically.
Since realistically we're initialising the engine here we don't want to do that, since String should not require an engine startup to test a single header.
This lowers the complexity of running the unit tests and even for
physics should be possible to implement such a fix.
The base branch is hardcoded as an env variable as I couldn't find a simple
way to just get either `3.2` or `master`. But it's easy to change when we
branch off from `master` to a new stable branch, which doesn't happen often.
(There's `{{github.base_ref}}` but it's probably more verbose like
`ref/heads/master`, and only valid for PRs.)
