- Use -gdwarf-4 to support both LLVM and GCC when calling addr2line
- Subtract position-independant execuable relocation when passing the
address to addr2line
(cherry picked from commit 5e041eee11)
Adds support for LTO on macOS and Android.
Disable LTO by default on iOS even if `production=yes` is set.
Also add `linker` option to `server` platform missed in #63283.
Refactor code handling old arguments to make it simpler (breaks compat,
but is explicit enough about it and scripts are easy to fix).
This will allow adding developer checks which will be fully compiled out in
user builds, unlike `DEBUG_ENABLED` which is included in debug tempates and
the editor builds.
This define is not used yet, but we'll soon add code that uses it, and change
some existing `DEBUG_ENABLED` checks to be performed only in dev builds.
Related to https://github.com/godotengine/godot-proposals/issues/3371.
Stop include Bullet headers using `-isystem` for GCC/Clang as it misleads
SCons into not properly rebuilding all files when headers change.
This means we also need to make sure Bullet builds without warning, and
current version fares fairly well, there were just a couple to fix (patch
included).
Increase minimum version for distro packages to 2.90 (this was never released
as the "next" version after 2.89 was 3.05... but that covers it too).
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)
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)
`debug_symbols=yes` will now behave like `debug_symbols=full` did
before. The difference in compressed file sizes is not that large,
which means there isn't much point in having two different values.
This helps make the buildsystem easier to understand.
(cherry picked from commit ff1f0d2cb5)
Its last use was removed in Godot 3.0, so it no longer makes sense to define.
Also removed `D3D_DEBUG_INFO` for Windows as it's likely a left over from a
long time ago pre-opensourcing when Godot had some form of Direct3D 9 support?
(cherry picked from commit dcf902df85)
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)
This reverts commit 2e152b945f.
SCons `FRAMEWORKS` is, according to their latest docs, only supported
"On Mac OS X with gcc". While the "with gcc" part seems bogus, #36795
did introduce a link failure for our osxcross toolchain for compiling
macOS binaries from Linux. SCons probably fails to detect this as a
macOS target and does not use its `FRAMEWORKS` logic properly.
So using `LINKFLAGS` as we used to is the more portable solution.
- 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)
Fixes the link errors below
clang: error: no such file or directory: 'Carbon'
clang: error: no such file or directory: 'AudioUnit'
clang: error: no such file or directory: 'CoreAudio'
clang: error: no such file or directory: 'CoreMIDI'
clang: error: no such file or directory: 'IOKit'
clang: error: no such file or directory: 'ForceFeedback'
clang: error: no such file or directory: 'CoreVideo'
clang: error: no such file or directory: 'AVFoundation'
clang: error: no such file or directory: 'CoreMedia'
clang: error: no such file or directory: 'Metal'
clang: error: no such file or directory: 'QuartzCore'
Tested on
System Version: macOS 10.15.3 (19D76)
SCons by Steven Knight et al.:
script: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine path: ['/usr/local/Cellar/scons/3.1.2_1/libexec/scons-local/SCons']
Xcode 11.3.1
Build version 11C504
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.3.0
Closes#36720
(cherry picked from commit c924e83a64)
It's the recommended way to set those, and is more portable
(automatically prepends -D for GCC/Clang and /D for MSVC).
We still use CPPFLAGS for some pre-processor flags which are not
defines.
Wrapped libpng usage in a pair of functions under PNGDriverCommon,
which convert between Godot Image and png data.
Switched to libpng 1.6 simplified API for ease of maintenance.
Implemented ImageLoaderPNG and ResourceSaverPNG in terms of
PNGDriverCommon functions.
Travis, switched to builtin libpng (thus builtin freetype and zlib also)
so we can build on Xenial.
This updates our local copy to commit 5ec8339b6fc491e3f09a34a4516e82787f053fcc.
We need a recent master commit for some new features that we use in Godot
(see #25543 and #28909).
To avoid warnings generated by Bullet headers included in our own module,
we include those headers with -isystem on GCC and Clang.
Fixes#29503.
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.
Godot supports many different compilers and for production releases we
have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers
all do slightly different things with -ffast-math and it is causing
issues now. See #24841, #24540, #10758, #10070. And probably other
complaints about physics differences between release and release_debug
builds.
I've done some performance comparisons on Linux x86_64. All tests are
ran 20 times.
Bunnymark: (higher is better)
(bunnies) min max stdev average
fast-math 7332 7597 71 7432
this pr 7379 7779 108 7621 (102%)
FPBench (gdscript port http://fpbench.org/) (lower is better)
(ms)
fast-math 15441 16127 192 15764
this pr 15671 16855 326 16001 (99%)
Float_add (adding floats in a tight loop) (lower is better)
(sec)
fast-math 5.49 5.78 0.07 5.65
this pr 5.65 5.90 0.06 5.76 (98%)
Float_div (dividing floats in a tight loop) (lower is better)
(sec)
fast-math 11.70 12.36 0.18 11.99
this pr 11.92 12.32 0.12 12.12 (99%)
Float_mul (multiplying floats in a tight loop) (lower is better)
(sec)
fast-math 11.72 12.17 0.12 11.93
this pr 12.01 12.62 0.17 12.26 (97%)
I have also looked at FPS numbers for tps-demo, 3d platformer, 2d
platformer, and sponza and could not find any measurable difference.
I believe that given the issues and oft-reported (physics) glitches on
release builds I believe that the couple of percent of tight-loop
floating point performance regression is well worth it.
This fixes#24540 and fixes#24841
Also made LINK and CXXFLAGS configurable as command line options.
Note that LINK currently expects the *compiler* that will be used
for linking and will call its configured linker behind the scenes
(so g++, clang++, etc., not ld.gold). See #15364 for details.
