GitHub Actions seems to be hiding colored whitespace, and after lots of
attempts I couldn't find a way to work it around.
So instead I'm using a perl expression to replace trailing spaces with
`·` and tabs with `<TAB>` in the ANSI colored diff output. This ensure
that they're visible, and they are properly colored as expected too.
The default environment already includes everything we need to build
all our configurations.
Remove custom SwiftShader setup as lavapipe should now be good enough,
but we need to install the latest one.
- Unify keycode values (secondary label printed on a key), remove unused hardcoded Latin-1 codes.
- Unify IME behaviour, add inline composition string display on Windows and X11.
- Add key_label (localized label printed on a key) value to the key events, and allow mapping actions to the unshifted Unicode events.
- Add support for physical keyboard (Bluetooth or Sidecar) handling on iOS.
- Add support for media key handling on macOS.
Co-authored-by: Raul Santos <raulsntos@gmail.com>
Follow-up to https://github.com/godotengine/godot-cpp/pull/960.
Fix exit code for --dump-extension-api and --dump-gdextension-interface.
Removed the planned API validation step as we still didn't implement
anything, and maintaining a stub isn't useful.
Non-exhaustive list of case-sensitive renames:
GDExtension -> GDNative
GDNATIVE -> GDEXTENSION
gdextension -> gdnative
ExtensionExtension ->Extension (for where there was GDNativeExtension)
EXTENSION_EXTENSION ->EXTENSION (for where there was GDNATIVE_EXTENSION)
gdnlib -> gdextension
gdn_interface -> gde_interface
gdni -> gde_interface
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.
Use isutf8 instead of recode to detect invalid UTF-8 sequences.
Also add the necessary dependencies to run the static checks locally
using act (https://github.com/nektos/act) with the Medium size image.
Update export names (web[_dlink]_[release|debug].zip).
The Build with dynamic linking is broken due to high number of imports
in output wasm (likely emscripten regression issue 15487).
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.
A second build is no longer needed. It was resulting in a null build
that still took more than 1 minute of CI time.
Also removed other usages of `mono_glue=no` and `mono_static=yes`,
as these options no longer exist.
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
The new option is `linker` and lets the user specify the argument to
the`-fuse_ld=` linker flag directly. The supported options are:
- `default`: No change, typically uses GNU ld (bfd) unless the user or
distro picked a different default `/usr/bin/ld`.
- `bfd`: GNU ld from binutils
- `gold`: GNU gold from binutils
- `lld`: lld from LLVM
- `mold`: mold, an extremely fast modern linker, not (yet) intended for
use in production but great for development speed. Provided by distro
`mold` package or needs to be compiled from source and installed to
`/usr` otherwise.
Removes the `use_lld=yes` option, and make lld actually usable with GCC
too.
Not all the above are compatible or recommend for LTO, we recommend
using GNU ld with GCC LTO, or lld with LLVM ThinLTO.
