It seems that we are only enabling this option together with unsafe
build determinators. However it seems that MD5-timestamp by itself is
not unsafe.
MD5-Timestamp works by first checking the timestamp of a file, comparing
it to the scons database and if it does not match it will do an md5sum
to determine if the file needs rebuilding.
Without this option SCons will always create md5sums of every file. In
the case of a null build this is 50% of the time.
(cherry picked from commit 04fff3fe0d)
The `env.disabled_modules` and `methods.disable_module` weren't used anywhere
so the first one was repurposed and the second just deleted
Signed-off-by: Yevhen Babiichuk (DustDFG) <dfgdust@gmail.com>
(cherry picked from commit 8e75e029b3)
Prevents cache issues by not purging cache before starting a build.
Splits cache purge related code from progress code and delays the purge
until after final build is done.
(cherry picked from commit acffc53e01)
Some of the logic in SCons depends on flags that get overridden in the
platform-specific `detect.py`, so it needs to be processed first.
For example the Android/iOS/Web platforms override the default `target`
to `template_debug`, but this was processed too late so e.g. the logic
that sets `env.editor_build` would set it to true due to the default
`target` value in the environment being `editor`.
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.
