summaryrefslogtreecommitdiffstats
path: root/platform/android/detect.py
Commit message (Collapse)AuthorAgeFilesLines
* Increase compiler optimization when using `target=release` on iOS/AndroidHugo Locurcio2022-05-131-2/+5
|
* Misc build system fixesAaron Franke2021-12-101-1/+1
|
* SCons: Set `DEBUG_ENABLED` and `DEV_ENABLED` in SConstructRémi Verschelde2021-10-151-4/+1
| | | | | They're the same for all platforms so they don't need to be repeated in all platform definitions.
* SCons: Add `DEV_ENABLED` defines for `target=debug` buildsRémi Verschelde2021-10-141-0/+1
| | | | | | | | | | | 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 godotengine/godot-proposals#3371.
* Build for 64-bit ARM by default when compiling or exporting for AndroidHugo Locurcio2021-10-121-17/+6
| | | | | | | All Android devices that support Vulkan support 64-bit ARM. This also removes NEON opt-out code for ARMv7 as pretty much all ARMv7 devices also support NEON.
* Replace HTTP links with HTTPS for sites with HTTPS versionsAaron Franke2021-08-221-1/+1
|
* Android: Use volk instead of NDK Vulkan headersRémi Verschelde2021-08-121-1/+0
| | | | | We no longer build the Vulkan loader, and volk lets us load it dynamically. Roblox uses volk on Android so it should work well for us too.
* Use "volk" instead of statically linked Vulkan loader.bruvzg2021-08-121-2/+8
|
* Android: Remove `-fno-integrated-as`, it can break arm64v8 buildRémi Verschelde2021-05-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | We found that this flag causes this error on PR #48812 which does not add any fancy inline assembly: ``` /tmp/tile_set-ce236a.s: Assembler messages: /tmp/tile_set-ce236a.s:34676: Error: selected processor does not support `bfc x0,#32,#32' clang++: error: assembler command failed with exit code 1 (use -v to see invocation) ``` That flag is mentioned in various errors related to assembler failures on arm64v8 with Clang from the Android NDK. It was added in Godot in #6958 when migrating from GCC to Clang, and is indeed referenced in the NDK's Clang migration guide: https://android.googlesource.com/platform/ndk/+/master/docs/ClangMigration.md > Especially for ARM and ARM64, Clang is much stricter about assembler rules > than GCC/GAS. Use `-fno-integrated-as` if Clang reports errors in inline > assembly or assembly files that you don't wish to modernize. We don't get those errors nowadays so it seems the flag is no longer needed.
* Make all file access 64-bit (uint64_t)Pedro J. Estébanez2021-05-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the types of a big number of variables. General rules: - Using `uint64_t` in general. We also considered `int64_t` but eventually settled on keeping it unsigned, which is also closer to what one would expect with `size_t`/`off_t`. - We only keep `int64_t` for `seek_end` (takes a negative offset from the end) and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means we only need to guard against passing negative values in `core_bind.cpp`. - Using `uint32_t` integers for concepts not needing such a huge range, like pages, blocks, etc. In addition: - Improve usage of integer types in some related places; namely, `DirAccess`, core binds. Note: - On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for big files on 32-bit Windows builds made with that toolchain. We might add a workaround. Fixes #44363. Fixes godotengine/godot-proposals#400. Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
* [JS, Android] Re-add "no-exceptions" for export templates builds with ICU.bruvzg2021-04-201-1/+3
|
* Allow to not optimize release buildRafał Mikrut2021-03-141-3/+2
|
* Override `ANDROID_NDK_ROOT` based on the project ndk version.Fredia Huya-Kouadio2021-02-171-8/+5
| | | | This helps resolve issues where the project ndk version differs from the one pointed by the `ANDROID_NDK_ROOT` environment variable (if it exists).
* Android: Bump NDK version to 21.4.7075529Rémi Verschelde2021-02-181-1/+1
| | | | | | This is what GitHub Actions now provide and they removed the previous 21.3.6528147. A bit annoying to have our hand forced this way but it's still 21.x so should be good to upgrade.
* Improve the logic to compile for Android by automatically detecting and ↵Fredia Huya-Kouadio2021-01-051-4/+57
| | | | setting up the Android NDK if needed.
* Don't handle BaseException in build scriptsMarcel Admiraal2020-12-121-1/+1
|
* [Complex Text Layouts] Add third-party TextServer dependencies (ICU, ↵bruvzg2020-11-261-1/+1
| | | | HarfBuzz, Graphite).
* CI: Install master version of psf/blackRémi Verschelde2020-07-261-3/+8
| | | | | | | Until https://github.com/psf/black/pull/1328 makes it in a stable release, we have to use the latest from Git. Apply new style fixes done by latest black.
* SCons: Remove unused DEBUG_MEMORY_ENABLED defineRémi Verschelde2020-07-231-1/+1
| | | | | | | 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?
* Vulkan rendering for AndroidPouleyKetchoupp2020-04-031-4/+4
|
* SCons: Format buildsystem files with psf/blackRémi Verschelde2020-03-301-101/+140
| | | | | | | | | | | | | | | | | | | | | 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.
* Removed unused code in android detect.py and SCsubunknown2020-03-181-5/+0
|
* Compilation fixes on AndroidPouleyKetchoupp2020-03-041-1/+0
|
* Android: Style fixes to manifest and build.gradleRémi Verschelde2019-08-271-11/+9
|
* Android: Remove unusable android_stl=no optionRémi Verschelde2019-07-301-5/+6
| | | | | | | | | | | As of 3.1 and later, we have too many thirdparty C++ dependencies and some internal uses of `new` and `delete` too for it to make sense to build without the STL on Android. The option has been broken since 3.0, and the "System STL" that we relied on for basic support of `new` and `delete` is likely to be dropped from the NDK: https://android.googlesource.com/platform/ndk/+/ndk-release-r20/docs/BuildSystemMaintainers.md#System-STL
* Android: Drop support for NDK < r15Rémi Verschelde2019-07-301-25/+18
| | | | | | NDK r15c was released over two years ago (July 2017), and we cannot build against r14b anyway as it seems to fail with our setup to link the STL.
* SCons: Use CPPDEFINES instead of CPPFLAGS for pre-processor definesRémi Verschelde2019-07-031-11/+12
| | | | | | | | 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.
* Deprecate armv6 support for Androidfhuya2019-06-191-14/+2
|
* SCons: Keep exceptions and rtti on Android, iOS and HTML5 tools buildRémi Verschelde2019-05-201-2/+3
| | | | | | | | | | 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.
* Merge pull request #28518 from clayjohn/GLES2-MSAARémi Verschelde2019-05-131-1/+1
|\ | | | | Added MSAA to GLES2 backend
| * added MSAA to GLES backendclayjohn2019-05-021-1/+1
| |
* | SCons: Always use env.Prepend for CPPPATHRémi Verschelde2019-04-301-1/+1
|/ | | | | | 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).
* SCons: Review uses of CCFLAGS, CXXFLAGS and CPPFLAGSRémi Verschelde2019-04-241-21/+27
| | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove unused importsHendrikto2019-04-061-1/+0
|
* SCons: Move platform-specific Opus config to its moduleRémi Verschelde2019-03-021-6/+0
|
* SCons: Drop unused MPC_FIXED_POINT defineRémi Verschelde2019-01-161-1/+1
|
* Android: Add support for x86_64 architectureRémi Verschelde2019-01-161-2/+15
| | | | | | | Like arm64v8, this is only supported by API 21 and later, so we enforce 21 as min API for x86_64. Part of #25030.
* Don't use -ffast-math or other unsafe math optimizationsHein-Pieter van Braam2019-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove trailing whitespaceRémi Verschelde2018-11-201-3/+3
| | | | | With `sed -i $(rg -l '[[:blank:]]*$' -g'!thirdparty') -e 's/[[:blank:]]*$//g'` (+ manual revert of some thirdparty code under `platform/android`).
* Dont use equality operators with None singleton in python fileslupoDharkael2018-10-271-2/+2
|
* No need to link with libandroid_support in NDK 17Wojciech Milkowski2018-08-281-1/+2
| | | | | | According to https://github.com/bytedeco/javacpp/pull/244 in NDK 17 libandroid_support library is not needed any more, and on armv8 is already gone which breaks compilation.
* Merge pull request #20507 from rdhafidh/android_libcpp_shared_masterRémi Verschelde2018-08-231-14/+23
|\ | | | | add support libc++_shared on android (master)
| * add support libc++_shared stl on androidRidwan Abdul Hafidh2018-08-231-14/+23
| |
* | Update detect.pyTiago Quendera2018-08-171-1/+1
|/ | | Fixed a typo in detect.py
* -Fix disable_3d flagJuan Linietsky2018-07-211-2/+7
| | | | -Add extra flag optimize=[size,speed] to be able to prioritize size
* Fixed android arm64v8Colin Kinloch2017-12-231-6/+13
|
* Fixed Android NDK unified header detection for python 3Colin Kinloch2017-12-171-1/+1
|
* Cleanup old references to GLES2 rendererRémi Verschelde2017-11-191-1/+1
| | | | | | | | | 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.
* change matrix and enable caching for Android, iOS and macOS (cross-compile)Rhody Lugo2017-11-131-2/+9
|
* add missing distutils.version.LooseVersion importRhody Lugo2017-11-091-0/+1
|