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)
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.
This PR introduces support for ARKit to the iOS version of Godot.
ARKit is Apples Augmented Reality platform.
This PR brings in support for ARKit 1.0 and implements a few ARKit 2.0 features.
It requires iOS 11 to run but should not prevent Godot from running on older versions as long as ARKit remains unused.
This is a new singleton where camera sources such as webcams or cameras on a mobile phone can register themselves with the Server.
Other parts of Godot can interact with this to obtain images from the camera as textures.
This work includes additions to the Visual Server to use this functionality to present the camera image in the background. This is specifically targetted at AR applications.
Those were disable to keep size small, and on Android avoid the dependency on the STL,
but for tools build (editor) this is not really a concern.
Note: as of today it's not possible to build tools=yes for those platforms, but this
change is one of the necessary steps to enable it.
Fixes#25262.
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
Previously the compiler would use system headers located at
/System/Library/Frameworks, which could result in compilation failures
due to the headers not always being up-to-date in regards to the
latest installed macOS SDK headers that come with Xcode.
Fix the issue by passing the SDK path via the -isysroot option to the
compiler and linker invocations.
If no custom SDK path is given, the build system queries the SDK path
via xcrun --show-sdk-path, which returns something similar to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
/Developer/SDKs/MacOSX.sdk/
Querying via xcrun is now also done for iphone (and simulator)
platforms as well.
Here is an example of a compilation failure message due to outdated
headers:
platform/osx/os_osx.mm:1421:41: error: use of undeclared identifier 'NSAppKitVersionNumber10_12'; did you mean 'NSAppKitVersionNumber'?
if (floor(NSAppKitVersionNumber) >= NSAppKitVersionNumber10_12) {
^~~~~~~~~~~~~~~~~~~~~~~~~~
NSAppKitVersionNumber
/System/Library/Frameworks/AppKit.framework/Headers/NSApplication.h:26:28: note: 'NSAppKitVersionNumber' declared here
- EditorExportPlugin's _export_begin accepts all the arguments related
to the current export (is_debug, path, flags).
- EditorExportPlugin API is extended with methods allowing to configure
iOS export: add_ios_framework, add_ios_plist_content,
add_ios_linker_flags, add_ios_bundle_file.
- iOS export template now contains Godot as a static library so that
it can be linked with third-party Frameworks and GDNative static
libraries.
- Adds method to DirAccess for recursive copying of a directory.
- Fixes iOS export to work with Xcode 9 (released recently).
There are still some left in the Android Java code, even stuff to swap between
GLES1 and GLES2 support from early Godot days... would be good to see some cleanup
there too one day.
The "graphics/api" option for Android exports is removed, as only GLES 3.0 is supported.
It can be readded when GLES 2.0 support comes back. Fixes#13004.
- The Windows, UWP, Android (on Windows) and Linux builds are
tested with Scons 3.0 alpha using Python 3.
- OSX and iOS should hopefully work but are not tested since
I don't have a Mac.
- Builds using SCons 2.5 and Python 2 should not be impacted.
Tried to organize the configure(env) calls in sections, using the same order
for all platforms whenever possible.
Apart from cosmetic changes, the following issues were fixed:
- Android: cleanup linkage, remove GLESv1_CM and GLESv2
- iPhone: Remove obsolete "ios_gles22_override" option
- OSX:
* Fix bits detection (default to 64) and remove obsolete "force_64_bits" option
(closes#9449)
* Make "fat" bits argument explicit
- Server: sync with X11
- Windows: clean up old DirectX 9 stuff
- X11:
* Do not require system OpenSSL for building (closes#9443)
* Fix typo'ed use_leak_sanitizer option
* Fix .llvm suffix overriding custom extra_suffix
All the warnings are factored out of the platform-specific files and moved to
SConstruct. Will have to check that it does not introduce regressions on some
platforms/compilers.
(cherry picked from commit 31107daa1a)
Took the opportunity to undo the Godot changed made to the
opus source. The opus module should eventually be built in its
own environment to avoid polluting others with too many include
dirs and defines.
TODO: Fix the platform/ stuff for opus.
