Instead of hardcoding platform names that support C#, let platforms
set a flag indicating if they support it. All public platforms
except web already support it, and it's a pain to maintain a patch
for this list just to add additional names of proprietary console
platforms.
This makes adding new platforms or variants or existing platforms
much easier, as the platform can signal what it supports/doesn't
support directly, and we can avoid harcoding platform names.
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>
Credit and thanks to @bruzvg for multiple build fixes, update of 3rd-party items and MinGW support.
Co-authored-by: bruvzg <7645683+bruvzg@users.noreply.github.com>
Follow-up to #75932.
Since these icons are only used by the export plugin, it makes sense to
move them and generate the headers there.
The whole `detect.is_active()` logic seems to be a leftover from before
times, as far back as 1.0-stable it already wasn't used for anything.
So I'm removing it and moving the export icon generation to
`platform_methods`, where it makes more sense.
Adds a new OS::get_system_ca_certs method which can be implemented by
platforms to retrieve the list of trusted CA certificates using OS
specific APIs.
The function should return the certificates in PEM format, and is
currently implemented for Windows/macOS/LinuxBSD(*)/Android.
mbedTLS will fall back to bundled certificates when the OS returns no
certificates.
(*) LinuxBSD does not have a standardized certificates store location.
The current implementation will test for common locations and may
return an empty string on some distributions (falling back to the
bundled certificates).
Follow-up to #69294 which enabled it automatically for `dev_build=yes`,
but this seems to cause some issues.
Those issues should likely be debugged but until then this can stay opt-in.
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.
- `_DEBUG` is MSVC specific so it didn't make much sense to define for
Android and iOS builds.
- iOS was the only platform to define `DEBUG`. We don't use it anywhere
outside thirdparty code, which we usually don't intend to debug, so it
seems better to be consistent with other platforms.
- Consistently define `NDEBUG` to disable assert behavior in both `release`
and `release_debug` targets. This used to be set for `release` for all
platforms, and `release_debug` for Android and iOS only.
- Due to the above, I removed the only use we made of `assert()` in Godot
code, which was only implemented for Unix anyway, should have been
`DEV_ENABLED`, and is in PoolAllocator which we don't actually use.
- The denoise and recast modules keep defining `NDEBUG` even for the `debug`
target as we don't want OIDN and Embree asserting all over the place.
Adds support for LTO on macOS and Android. We don't have much experience
with LTO on these platforms so for now we keep it disabled by default
even when `production=yes` is set.
Similarly for iOS where we ship object files for the user to link in
Xcode so LTO makes builds extremely slow to link.
`production=yes` defaults to full LTO.
ThinLTO is much faster for LLVM-based compilers but seems to produce
bigger binaries (at least for the Web platform).
Previously it was used only on debug builds, but recent
additions to variant_call.cpp have made that unit too
large even in release_debug.
It was originally set to debug only because using it
breaks mingw, so this only reinstates it for MSVC where
it shouldn't have any drawbacks (famous last words).
Test-Information:
Builds for me with
scons -j 40 platform=windows target=release_debug
and my game then runs from it.
fixed and simplified gl_manager_windows
swap buffers now called for all windows
fixed missing pixel format setting in additional windows
this makes them work in OpenGL contexts
changed verbose error printing to write once
this error message happens very frequently while opengl3 is not finished
removed dead code no longer needed after changes
fixed comments that were misinformation
window messages during window creation now handled
these were previously discarded
messages now tunnel the required context
changed failure to create opengl3 window on windows to be more fatal
marked a problem with pen code
conditional compilation of vulkan and opengl3 on windows fixed
windows debug builds now show messages on debug console also
rendering driver selection box now shows only compiled drivers
marked some problematic code
thanks to akien-mga for patiently rewriting my style mistakes
Always build with the GUI subsystem.
Redirect stdout and stderr output to the parent process console.
Use CreateProcessW for blocking `execute` calls with piped stdout and stderr (prevent console windows for popping up when used with the GUI subsystem build, and have more consistent behavior with `create_process`).
Add `open_console` argument to the `execute` and `create_process` to open a new console window.
Remove `interface/editor/hide_console_window` editor setting.
Remove `Toggle System Console` menu option.
Remove `set_console_visible` and `is_console_visible` functions.
Building `target=release` and `target=release_debug` builds with MinGW-GCC
errors when linking with LTO.
Since it's only needed for `target=debug` builds anyway (bigger objects), which
we don't build with LTO, this works around the issue.
Equivalent `-Wa,-mbig-obj` for GCC/Clang.
This started being needed to compile harfbuzz in `target=debug` with MinGW/GCC,
but there doesn't seem to be any drawback to enabling `/bigobj` (aside from
losing support for pre-VS 2005 linkers, which we don't support).