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.
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.
