This fixes a regression from #46774 where `env["ENV"]` would miss some
important env variables on Windows, such as `SystemRoot`, `PATHEXT`, etc.
So we go back to the previous setup (letting SCons initialize `env["ENV"]`
as it sees fit for the host OS) but use `PrependENVPath` instead of
`AppendENVPath` to preserve the intended fix from #46774.
Fixes#46790 for 3.2.
We constructed the SCons environment without taking any (shell) environment
variables into account, and then appended a few, but too late. This would
cause variables like `env[CXX]` not to be properly expanded to respect a
non-standard `PATH`.
With this fix, setting:
```
PATH=$GODOT_SDK/bin:$PATH
```
will now properly use `$GODOT_SDK/bin/gcc` if available over `/usr/bin/gcc`.
(cherry picked from commit 5d217a9441)
The `dev=yes` and `production=yes` options work as aliases to set a number of
options, while still aiming to allow overriding specific options if the user
wishes so. (E.g. `production=yes use_lto=no` should work to enable production
defaults *but* disable LTO.)
That wasn't working as `ARGUMENTS.get()` returns a string and not a boolean as
expected by `BoolVariable`, and this wasn't flagged as a bug... So added a
helper method using SCons' `BoolVariable._text2bool` to do the conversion
manually.
This adds `custom_modules_recursive` which allows to detect and collect
all nested C++ modules which may reside in any directory specified by
`custom_modules` option.
The detection logic is made to be more strict because `SCSub` may be
used for organizing hierarchical builds within a module itself, so the
existence of `register_types.h` and `config.py` is checked as well
(these are all required for a C++ module to be compiled by Godot).
For performance reasons, built-in modules are not checked recursively,
and there's no benefit of doing so in the first place.
It's now possible to specify a directory path pointing to a *single*
module, as it may contain nested modules which are detected recursively.
(cherry picked from commit a3c2c1e18a)
This is meant for users making custom builds to match the options used on
optimized, official builds.
This enables, on the platforms which support them:
- `use_static_cpp=yes` (portable binaries for Linux and Windows)
- `use_lto=yes` (link time optimizations - note: requires a lot of RAM!)
- `debug_symbols=no` (no debug symbols, smaller binaries)
Also abort when using MSVC with `production=yes`, as:
- It cannot optimize the GDScript VM like GCC or Clang do, leading to
significant performance drops.
- Its LTO support is unreliable, at least used to trigger crashes last
we tried it extensively.
All options can still be overridden if specified, and the `dev=yes` option
was changed to also support overrides.
(cherry picked from commit db26871210)
Fixes a pre-existing bug that #44433 exposed.
It's pretty hacky, but we use `platform` in `env` both as an optional command
line option (instead it can be autodetected, or passed via the `p` alias, and
on Linux it might be overridden if you pass one of the convenience alias
values), and as the reference value for what platform we're building on.
Thus we override `env_base["platform"]` with the autodetected or validated
platform, but any call to `opts.Update(env_base)` overrides it with the
original command line option... causing e.g. #44448.
The proper fix would be to refactor all this so that we don't reuse
`env["platform"]` for platform detection (it could instead be e.g.
`env.platform` as a member variable which holds the validated value),
but for now I'm tapering over the immediate breakage.
Fixes#44448 and other breakages induced by #44433.
(cherry picked from commit 8f660393fe)
Otherwise we can get situations where platform-specific opts with the same name
can override each other depending on the order at which platforms are parsed,
as was the case with `use_static_cpp` in Linux/Windows.
Fixes#44304.
This also has the added benefit that the `scons --help` output will now only
include the options which are relevant for the selected (or detected) platform.
(cherry picked from commit 0f84d8dc49)
A new `methods.dump(env)` is added to dump the construction environment
used by SCons to build Godot to a `.scons_env.json`. The file can be used
for debugging purposes and any external tool.
(cherry picked from commit 42bee75e86)
Some required changes are made:
- locally imported SCons-specific packages within the method;
- `global` variables converted to `nonlocal` (used in nested functions).
(cherry picked from commit d753a7630a)
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
(cherry picked from commit cd4e46ee65)
The `custom_modules` option was only read via the command line
by fetching `ARGUMENTS` dictionary directly.
Instead, the option's value can now be read via any existing
configuration files (`custom.py`) as well as command line, while also
updating the environment.
(cherry picked from commit 6304d16915)
The insertion order for dictionaries is only a language feature for
Python 3.6/3.7+ implementations, and not prior to that.
This ensures that the engine won't be rebuilt if the order of detected
modules changes in any way, as the `OrderedDict` should guarantee
inerstion order.
This patch adds ability to include external, user-defined C++ modules
to be compiled as part of Godot via `custom_modules` build option
which can be passed to `scons`.
```
scons platform=x11 tools=yes custom_modules="../project/modules"
```
Features:
- detects all available modules under `custom_modules` directory the
same way as it does for built-in modules (not recursive);
- works with both relative and absolute paths on the filesystem;
- multiple search paths can be specified as a comma-separated list.
Module custom documentation and editor icons collection and generation
process is adapted to work with absolute paths needed by such modules.
Also fixed doctool bug mixing absolute and relative paths respectively.
Implementation details:
- `env.module_list` is a dictionary now, which holds both module name as
key and either a relative or absolute path to a module as a value.
- `methods.detect_modules` is run twice: once for built-in modules, and
second for external modules, all combined later.
- `methods.detect_modules` was not doing what it says on the tin. It is
split into `detect_modules` which collects a list of available modules
and `write_modules` which generates `register_types` sources for each.
- whether a module is built-in or external is distinguished by relative
or absolute paths respectively. `custom_modules` scons converter
ensures that the path is absolute even if relative path is supplied,
including expanding user paths and symbolic links.
- treats the parent directory as if it was Godot's base directory, so
that there's no need to change include paths in cases where custom
modules are included as dependencies in other modules.
(cherry picked from commit a96f0e98d7)
There's a builtin `toolpath` option we can use for that, so no need to hack
around a custom `scons_site` path.
The script requires SCons 3.1.1 or later, so we enable it conditionally.
Follow-up to #32848.
(cherry picked from commit 22c718ab17)
This tool is originally from mongodb.
- Updated CPPSUFFIXES to use scons suffixes
- objective-c files will also be loaded into the compilation database where the compiler / tooling is available to compile the files.
Known limitations:
- This will not work with msvc as your compiler.
(cherry picked from commit 5a6f275b74)
- Improve the SCsub to allow unbundling and remove unnecessary code.
- Move files around to match upstream source.
- Re-sync with upstream commit 308db73d0b3c2d1870cd3e465eaa283692a4cf23
to ensure we don't have local modifications.
- Doesn't actually build against current version 5.0.1 due to the lack
of the new ArmaturePopulate API that Gordon authored. We'll have to
wait for a public release with that API (5.1?) to enable unbundling.
(cherry picked from commit 9d8a9ea826)
Otherwise comparisons would fail for compiler versions above 10.
Also simplified code somewhat to avoid using subprocess too much
needlessly.
(cherry picked from commits c7dc5142b5
and df7ecfc4a7)
On GCC and Clang, we use C11 and C++14 with GNU extensions (`std=gnu11`
and `std=gnu++14`). Those are the defaults for current GCC and Clang,
and also match the feature sets we want to use in Godot.
On MSVC, we require C++14 support explicitly with `/std:c++14`, and
make it strict with the use of `/permissive-` (so features of C++17 or
later can't be used).
Moves the definition before querying environment flags and platform
config so that it can be overridden when necessary.
(cherry picked from commit 342f127362)
The new 'split_libmodules=yes' option is useful to work around linker
command line size limitations when linking a huge number of objects.
We're currently over 64k chars when linking libmodules.a on Windows
with MinGW, which triggers issues as seen in #30892.
Even on Linux, we can also reach linker command line size limitations
by adding more custom modules.
We force this option to True for MinGW on Windows, which fixes#30892.
Additional changes to lib splitting:
- Fix linking of the split module libs with interdependent symbols,
hacking our way into LINKCOM and SHLINKCOM to set the `--start-group`
and `--end-group` flags.
- Fix Python 3 compatibility in `methods.split_lib()`.
- Drop seemingly obsolete condition for 'msys' on 'posix'.
- Drop the unnecessary 'split_drivers' as the drivers lib is no longer
too big since we moved all thirdparty builds to modules.
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
Third-party platforms (e.g. console ports) need to be able to
disable JIT support in the regex module too, so it can't be
hardcoded in the module SCsub. This is cleaner this way anyway.
Fixes#19316.
- Add or remove the necessary subdirectorires to the includes to remove
dependency on the editor directory being in the build's include path.
- Ensure includes in modified files conform to style guideline.
- Remove editor from the build include path.
**Important:** This does not mean *yet* that C++11 features should be used
in contributions to Godot's codebase.
For now this change is done solely for feature branches working on Vulkan
support and GDScript typed instruction sets for Godot 4.0, which will both
use C++11 features and are based on the master branch.
The plan is to start porting the codebase to C++11 after Godot 3.2 is
released, following upcoming guidelines on the subset of new features that
should be used, and when/how to use them.
We will advertise clearly when C++11 contributions are open, especially
once we start a coordinated effort to port Godot's massive codebase. In the
meantime, please bear with us and good ol' C++03. :)
The functionality is similar to how `doc_classes` are retrieved per module.
The build system will search for custom icons path defined per module via
`get_icons_path()` method in `config.py` or default icons path.
If such paths don't exist, only the editor's own icons will be built.
Most module icons were moved from editor/icons to respective modules.
This can help to solve compilation issues on systems with Japanese
locale with encodings like Shift_JIS and UTF-8-BOM.
Also be more consistent using String::utf8() to represent cyrilic
unicode characters in test_string.cpp
Clarified some comments in test_string.cpp for some Unicode characters.
We're close to being able to compile all platforms with -Werror -Wextra,
so it's best if developers use those options when compiling their code
as those checks are also done on CI.
Also enabled -Wduplicated-branches on GCC.
Include paths are processed from left to right, so we use Prepend to
ensure that paths to bundled thirdparty files will have precedence over
system paths (e.g. `/usr/include` should have lowest priority).
Many contributors (me included) did not fully understand what CCFLAGS,
CXXFLAGS and CPPFLAGS refer to exactly, and were thus not using them
in the way they are intended to be.
As per the SCons manual: https://www.scons.org/doc/HTML/scons-user/apa.html
- CCFLAGS: General options that are passed to the C and C++ compilers.
- CFLAGS: General options that are passed to the C compiler (C only;
not C++).
- CXXFLAGS: General options that are passed to the C++ compiler. By
default, this includes the value of $CCFLAGS, so that setting
$CCFLAGS affects both C and C++ compilation.
- CPPFLAGS: User-specified C preprocessor options. These will be
included in any command that uses the C preprocessor, including not
just compilation of C and C++ source files [...], but also [...]
Fortran [...] and [...] assembly language source file[s].
TL;DR: Compiler options go to CCFLAGS, unless they must be restricted
to either C (CFLAGS) or C++ (CXXFLAGS). Preprocessor defines go to
CPPFLAGS.
Rémi Verschelde
Rafał Mikrut
Andrii Doroshenko (Xrayez)
Mateo Kuruk Miccino
Hugo Locurcio
Marcel Admiraal
Bartłomiej T. Listwon
Gordon MacPherson
Aaron Franke
Fabian Mathews
PouleyKetchoupp
Fabio Alessandrelli
dankan1890
Max Hilbrunner
marxin