Add optional `detect.py` `get_tools` method to let platforms register SCons
tools they need.
This helps move this logic out of SConstruct, keeping platforms more self
contained, and helping thirdparty platforms define their own custom tools.
This logic was also unreliable (the `use_mingw` one would only work if
passed manually on the command line, not in e.g. `get_flags`).
Co-authored-by: Thaddeus Crews <repiteo@outlook.com>
This speeds up build time considerably for these platforms compared to
using `lto=full`, which is sadly single-threaded with LLVM, unlike GCC.
Changes to default behavior of `lto=auto` (i.e. `production=yes`):
- Linux: Prefer ThinLTO for LLVM
- Web: Prefer ThinLTO
- Windows: Prefer ThinLTO for llvm-mingw
The following LLVM targets don't use LTO by default currently, which
needs to be assessed further (gains from LLVM LTO on performance need
to be weighed against the potential size increase from heavy inlining):
- Android
- iOS
- macOS
- Windows clang-cl
Godot has a ScriptProcessorNode audio driver implementation for the
(deprecated) Web API.
As reported by some users, this fallback was not properly re-added
during the Godot 4 transition, and was left as "dead code".
While the API is deprecated, it is still supported by most browsers, and
some WebView may not implement AudioWorklet correctly (the new
recommended API).
This commit re-adds the ScriptProcessorNode implementation as a fallback
if the AudioWorklet driver fails to initialized (and can be forced if
desired via project settings as usual).
Fixes#95897
During CI scenarios $HOME may be set to an invalid value (such as
`/var/empty`).
Using temp dirs fits better with godot's usage of these paths and is
independent from the user's $HOME.
This makes the class available to avoid spam from classes using it, even
if without any actual implementation (since raw sockets are not
available on the web).
Note: This commit ties the IPUnix to the UNIX_SOCKET_UNAVAILABLE define,
disabling it when set. It is maybe not semantically correct (getifaddrs)
is not part of the "socket" API, but it's reasonable to expect that a
platform not supporting Unix-style sockets, would also not support other
Unix network functions.
They are not supported anyway, emscripten has an emulation layer that
implements them over WebSocket/WebRTC, which is really surprising for
users, and also not very useful since we have proper WebSocket and
WebRTC support.
This can make the build smaller, if we also disable the UPNP module
(which will otherwise include a third party library referencing "socket"
thus forcing emscripten to include the compatibility layer)
