The min SCons version had to be bumped as SCons 3.0 before 3.0.3 seems
broken (see #92043), and there's little gain from supporting 3.0.3-3.0.5.
3.1.2 is also the first version to avoid ambiguities between Python 2
and Python 3 usage, so we finally use it as the minimum baseline.
Also test against Python 3.6 which is also our minimum supported version.
This should help prevent regressions whenever we modernize the build scripts.
- GCC 7 supports C++17 but seems to have breaking regressions, see #79352.
- GCC 8 broke C++17 guaranteed copy elision support, fixed in 8.4, but...
- GCC 9 is old enough (2022) to use as a baseline and stop dealing with
unmaintained and less efficient compiler versions.
Finally reading the docs for `SCons.Variables.Update` let me find this optional
parameter, which solves the hacks and pain we've dealt with for years:
> args (optional) – a dictionary of keys and values to update in env.
> If omitted, uses the variables from the commandline.
By passing the environment itself, we preserve the values we've overridden in
`SConstruct` or `detect.py`.
With this option turned on, if properly set up, SCons generates a
`build.ninja` file and quits. To actually build the engine, the user can
then call `ninja` with whatever options they might prefer (not
everything is yet transferred properly to this new generated file).
Ideally, the scons file should never be called again, as ninja
automatically detects any SCons build script change and invokes
the required commands to regenerate itself.
This approach speeds up incremental builds considerably, as it limits
SCons to code generation and uses ninja's extremely fast timestamp-based
file change detector.
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.
