SConscript("some SCsub path") calls create a new context where a relative path
to the .sconsign file is interpreted as being next to the currently executing
SCsub, and not the one at the root. This breaks incremental build detection
because scons can't find the build information of dependent files outside of the
SCsub directory and just rebuilds everything every time.
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
```
This allows custom environment variables to be used during the build,
which is useful when using alternative compilation tools such as caches
and distributed build systems.
This is useful to speed up iteration when working on the engine
(or editor).
This can be combined with a script that calls `adb` to deploy the APK
on a device (coupled with Godot's `--export-*` for projects)
to further speed up iteration.
Verbose output is meant for debugging the SCU mode itself and can be
triggered by changing the `_verbose` bool manually.
Prefix all prints with "SCU:" for context, and print the processed
folders all at once instead of when adding the sources.
Add `object_prefix` as an scons option to add a custom prefix to
all generated object files, via the `OBJPREFIX` and `SHOBJPREFIX`
environment variables.
This is useful for instance to hide object files on unix-like
systems and make the source directories less cluttered by
setting `object_prefix = '.'` in `custom.py`.
Upon investigating the extremely slow MSVC build times in #80513, I noticed
that while Godot policy is to never use exceptions, we weren't enforcing it
with compiler flags, and thus still included exception handling code and
stack unwinding.
This is wasteful on multiple aspects:
- Binary size: Around 20% binary size reduction with exceptions disabled
for both MSVC and GCC binaries.
- Compile time:
* More than 50% build time reduction with MSVC.
* 10% to 25% build time reduction with GCC + LTO.
- Performance: Possibly, needs to be benchmarked.
Since users may want to re-enable exceptions in their own thirdparty code
or the libraries they compile with Godot, this behavior can be toggled with
the `disable_exceptions` SCons option, which defaults to true.
"scu_limit" allows specifying the maximum number of includes in a single SCU file (translation unit). A lower limit (e.g. 8) uses less RAM during compilation, but may be slower to compile.
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).
