The Godot Project Leadership Committe has decided to update the sponsoring
tiers so that the Platinum Sponsorship no longer includes a logo on the
editor splash screen.
This lets us reclaim the editor splash screen space for community-related
content instead of sponsors (e.g. a different community-designed splash
screen for each stable branch?).
Also removes two Platinum Sponsors whose sponsorship has expired earlier this
year.
When disabling specific modules, misspellings can occur. Additionally,
when switching between the `3.x` and `master` branches frequently,
it's possible to forget about renamed modules such as `lightmapper_cpu`
versus `lightmapper_rd`.
Note, the editor build requires the mbedtls module to be manually
enabled, as it is currently needed as a ResourceUID dependency.
This will need to be addressed in a separate PR.
- Rename OpenGL to GLES3 in the source code per community feedback.
- The renderer is still exposed as "OpenGL 3" to the user.
- Hide renderer selection dropdown until OpenGL support is more mature.
- The renderer can still be changed in the Project Settings or using
the `--rendering-driver opengl` command line argument.
- Remove commented out exporter code.
- Remove some OpenGL/DisplayServer-related debugging prints.
First implementation with Linux display manager.
- Add single-threaded mode for EditorResourcePreview (needed for OpenGL).
Co-authored-by: clayjohn <claynjohn@gmail.com>
Co-authored-by: Fabio Alessandrelli <fabio.alessandrelli@gmail.com>
We've had many issues with WebM support and specifically the libvpx library
over the years, mostly due to its poor integration in Godot's buildsystem,
but without anyone really interested in improving this state.
With the new GDExtensions in Godot 4.0, we intend to move video decoding to
first-party extensions, and this would likely be done using something like
libvlc to expose more codecs.
Removing the `webm` module means we can remove libsimplewebm, libvpx and
opus, which we were only used for that purpose. Both libvpx and opus were
fairly complex pieces of the buildsystem, so this is a nice cleanup.
This also removes the compile-time dependency on `yasm`.
Fixes lots of compilation or non-working WebM issues which will be linked
in the PR.
Current SCons 4.2.0 still supports Python 3.5 but deprecated it, and support
will be removed in the next release.
It's also become needlessly restrictive to prevent ourselves from using Python
3.6 f-Strings, so it's time to up the requirement.
They haven't really helped save much time on incremental rebuilds, and they do
cause potential issues with build correctness (and possibly even one of the cause
for overly eager incremental rebuilds).
Emscripten is LLVM-based so we want to follow the same logic. But we can't just
put it as a match in `methods.using_clang()` as that would mess with the
compiler version detection logic used to restrict old GCC and Clang releases.
It's raised for us on many comparators implemented to be able to store a struct
in `Set` or `Map` (who rely on `operator<` internally). In the cases I reviewed
we don't actually care about the ordering and we use the struct's function
pointers as that's the only distinctive data available.
* This PR adds the ability to disable classes when building.
* For now it's only possible to do this via command like:
`scons disable_classes=RayCast2D,Area3D`
* Eventually, a proper UI will be implemented to create a build config file to do this at large scale, as well as detect what is used in the project.
Debug builds are considerably slower than release builds or even
release_debug builds. `target=debug` is still the default SCons
target option, so unsuspecting users may be compiling unoptimized
debug builds for their personal use.
See discussion in #46814. Now going with the safe option again (like in 3.2)
as it turns out that we can't rely on user environments on Windows, since each
shell has a different set of env variables (especially the ones necessary to
use MSVC).
SCons does its own magic when we don't pass it an `ENV` dictionary, so we
should preserve it and only add things in a second step.
Fixes this warning when compiling with MSVC using git-bash.exe:
```
Missing environment variable: WindowsSdkDir
```
Possibly fixes build issues when having both MinGW and MSVC installed and an
older SCons version.
This fixes a regression from #46774 where `env["ENV"]` would miss some
important env variables on Windows, such as `SystemRoot`, `PATHEXT`, etc.
To have those, we can either use the default `ENV` created by SCons, or
propagate the whole external environment.
Fixes#46790.
We constructed the SCons environment without taking any (shell) environment
variables into account, and then appended a few, but too late. This would
cause variables like `env[CXX]` not to be properly expanded to respect a
non-standard `PATH`.
With this fix, setting:
```
PATH=$GODOT_SDK/bin:$PATH
```
will now properly use `$GODOT_SDK/bin/gcc` if available over `/usr/bin/gcc`.
The `dev=yes` and `production=yes` options work as aliases to set a number of
options, while still aiming to allow overriding specific options if the user
wishes so. (E.g. `production=yes use_lto=no` should work to enable production
defaults *but* disable LTO.)
That wasn't working as `ARGUMENTS.get()` returns a string and not a boolean as
expected by `BoolVariable`, and this wasn't flagged as a bug... So added a
helper method using SCons' `BoolVariable._text2bool` to do the conversion
manually.
This is meant for users making custom builds to match the options used on
optimized, official builds.
This enables, on the platforms which support them:
- `use_static_cpp=yes` (portable binaries for Linux and Windows)
- `use_lto=yes` (link time optimizations - note: requires a lot of RAM!)
- `debug_symbols=no` (no debug symbols, smaller binaries)
Also abort when using MSVC with `production=yes`, as:
- It cannot optimize the GDScript VM like GCC or Clang do, leading to
significant performance drops.
- Its LTO support is unreliable, at least used to trigger crashes last
we tried it extensively.
All options can still be overridden if specified, and the `dev=yes` option
was changed to also support overrides.
Fixes a pre-existing bug that #44433 exposed.
It's pretty hacky, but we use `platform` in `env` both as an optional command
line option (instead it can be autodetected, or passed via the `p` alias, and
on Linux it might be overridden if you pass one of the convenience alias
values), and as the reference value for what platform we're building on.
Thus we override `env_base["platform"]` with the autodetected or validated
platform, but any call to `opts.Update(env_base)` overrides it with the
original command line option... causing e.g. #44448.
The proper fix would be to refactor all this so that we don't reuse
`env["platform"]` for platform detection (it could instead be e.g.
`env.platform` as a member variable which holds the validated value),
but for now I'm tapering over the immediate breakage.
Fixes#44448 and other breakages induced by #44433.
