Using 2.2.7.dev217+g10c2abcf.
Had to add `colour` to the ignore list as we used it as an alias/keyword for the
documentation of color-related APIs.
Also ignore recommendations to change `thirdparty` to either `third-party` or
`third party`, which are correct but we use the former fairly consistently.
`pre-commit` can be installed with pip, and configured in the Godot repo with
`pre-commit install`. It can then easily be run both locally with
`pre-commit run`, and on CI, in a cross-platform way.
This makes it much easier for contributors to set up pre-commit hooks,
without having to manually copy files to their git folder.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
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
```
Not everything is yet implemented, either for Godot or personal
limitations (I don't have all hardware in the world). A brief list of
the most important issues follows:
- Single-window only: the `DisplayServer` API doesn't expose enough
information for properly creating XDG shell windows.
- Very dumb rendering loop: this is very complicated, just know that
the low consumption mode is forced to 2000 Hz and some clever hacks are
in place to overcome a specific Wayland limitation. This will be
improved to the extent possible both downstream and upstream.
- Features to implement yet: IME, touch input, native file dialog,
drawing tablet (commented out due to a refactor), screen recording.
- Mouse passthrough can't be implement through a poly API, we need a
rect-based one.
- The cursor doesn't yet support fractional scaling.
- Auto scale is rounded up when using fractional scaling as we don't
have a per-window scale query API (basically we need
`DisplayServer::window_get_scale`).
- Building with `x11=no wayland=yes opengl=yes openxr=yes` fails.
This also adds a new project property and editor setting for selecting the
default DisplayServer to start, to allow this backend to start first in
exported projects (X11 is still the default for now). The editor setting
always overrides the project setting.
Special thanks to Drew Devault, toger5, Sebastian Krzyszkowiak, Leandro
Benedet Garcia, Subhransu, Yury Zhuravlev and Mara Huldra.
This makes it much faster to get started with Direct3D 12 builds,
as you only need to run `python .\misc\scripts\install_d3d12_sdk_windows.py`
then run `scons d3d12=yes`.
This installs DirectX Shader Compiler, Mesa NIR, WinPixEventRuntime
and DirectX 12 Agility SDK.
- Define a default path that uses the locations from the script.
- Now the default path is in "%LOCALAPPDATA%\Godot\build_deps\"
- Updated CI to use this new python script.
Co-Authored-By: Hugo Locurcio <hugo.locurcio@hugo.pro>
Due to #82865, newer versions can't be used for dlink-enabled Web builds.
This isn't a problem for CI which doesn't use dlink, but it's clearer for
users if our CI version matches the one we use for official builds.
This used to be ignored as we ran the X11 version with Vulkan software renderer and xvfb-run, which could crash at the time. Now that we have headless mode, this is not a problem anymore.
This means that any PR which breaks the extension API should
handle it properly, that is:
- Add compatibility methods to ensure that existing function hashes work
- Document the changes in the relevant misc/extension_api_validation/ file
Useful for custom forks of Godot which don't want to run our CI for any
reason.
This is configured in `settings/variables/actions` for the repository,
setting it to any value aside from an empty string will skip all jobs.
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.
Removing the Android toolchain saves 14 GiB, which gives us more room
for growth and to avoid running into out-of-space errors in the Linux
sanitizers + debug symbols builds.
Related to #79919, though the caches were just one part of the problem,
the real issue is that our Linux sanitizers builds take 12 GiB, and
adding godot-cpp on top with 2 GiB leaves only a few GiB left for the
cache itself.
It's the slowest build so a speedup from SCU is welcome.
The other purpose of this change is to actually catch global scope
conflicts which would break the SCU build.
SCU builds have drawbacks as they won't fully validate that the
includes are correct, but we should have enough other builds in the CI
build matrix to catch this type of bug.
