Age | Commit message (Collapse) | Author |
|
When NDK r20+ is used along with Qt5.12, APK generation fails because
of the layout change in newer NDK. This patch introduces a new variable
USE_LLVM, when this is set for older Qt versions, androiddeployqt uses
LLVM's tools.
|
|
Also pass along these values to androiddeployqt
|
|
|
|
Summary:
Infer the toolchain we are using through cmake's detection of ranlib
instead of asking the user to fill it.
It's only used in androiddeployqt and cmake expects it to be version
"clang" for clang builds while androiddeployqt expects it to be "4.9".
Reviewers: #build_system, #android, vkrause
Reviewed By: #android, vkrause
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D16930
|
|
Summary:
Some projects such as marble do some operations with the APK directory
before building. This allows us the project to copy the apk directory
over to the build directory and do whatever it pleases.
Test Plan: Built Marble
Reviewers: #frameworks, vkrause
Reviewed By: vkrause
Subscribers: vkrause, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D13403
|
|
Otherwise androiddeployqt fails like it's failing now for kirigami
https://binary-factory.kde.org/view/Android/job/KirigamiGallery_android/48/console
|
|
concepts
Summary: Mark as deprecated the redundant variables and focus on the difference.
Reviewers: #build_system, #frameworks, vkrause
Reviewed By: vkrause
Subscribers: vkrause
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11984
|
|
Summary:
Instead of having ad-hoc code for gcc, let CMake do its thing. It has a lot of
logic that we may be interested in, for example it will make the clang switch
much smoother.
Note it raises the minimum cmake to 3.7 for Android, which was released almost
2 years ago.
Test Plan: Built kalgebra on it using kdeorg/android-sdk
Reviewers: #frameworks, #build_system, vkrause
Reviewed By: vkrause
Subscribers: vkrause
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11776
|
|
Summary:
This is needed for a new feature in Qt 5.12, making androiddepolyqt's
recursive dependency resolution avaiable for components installed in
different prefixes too.
This will allow us to drop our own partial ELF dependency parsing code
eventually, as well as avoid having to do workarounds like linking against
all indirect dependencies.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11388
|
|
Summary: qmake also generates it and androiddeployqt consumes it.
Test Plan: built and ran kalgebra
Reviewers: #frameworks, vkrause
Reviewed By: vkrause
Subscribers: vkrause, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11342
|
|
Summary:
This makes the qmlimportscanner find our QML files and plugins correctly.
That's IMHO much cleaner than the full copy of everything in the lib/qml
folder we do via the android-extra-plugins list.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11177
|
|
Summary:
The prefix for the command is i686-linux-android, while the toolchain is
x86 in this case. On ARM both values are the same.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10625
|
|
|
|
Summary:
When the QML files are all bundled into a .qrc file, they don't get
copied to the install dir, which would lead to qmlimportscanner not picking
up the dependencies (e.g. QtQuick Controls) for android packaging.
Looking at commit 1b0496d, I wonder if maybe we should be able to specify
two paths to look into? But qmlimportscanner doesn't support that, does it?
Test Plan:
using this toolchain for a basic QtQuick2 app created from a
QtCreator template, with Qt Quick Controls support, and QML files
in a Qt resource.
Reviewers: apol, mart
Reviewed By: apol
Subscribers: #build_system, #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6466
|
|
Summary:
set qml-root-path as the root install folder
of the application, as is used to scan for
import dependencies, and both qml files in share should be scanned
as well as other qml imports that may be installed in /lib
Test Plan: kirigami gallery deployment has again all the needed dependencies
Reviewers: apol
Reviewed By: apol
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D6103
|
|
Summary:
This way androiddeployqt will scan the imports.
Otherwise it wouldn't pull qtquickcontrols2 for me
Reviewers: #build_system, #frameworks, mart
Reviewed By: mart
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D5067
|
|
Just setting the field android-extra-plugins to an empty string resulted
in androiddeployqt complaining about
"External resource does not exist or not a correct directory!"
so the field is completely left out now if no plugin data dirs are found.
For consistency the same is done with the android-extra-libs field.
REVIEW: 127700
BUG: 362578
Thanks apol for review
|
|
* Remove get_property calls on targets, this way we don't need to be called
right before configuration time.
* Removes EOFHook
Instead we process it at generation time using the link.txt file (which is
probably another hack)
REVIEW: 125084
|
|
In general, we are looking for what we're installing, not for what we
already had.
|
|
|
|
Introduces the new Android toolchain file for being able to easily compile
our cmake projects in Android, with an emphasis on Qt projects.
CHANGELOG: New Android toolchain support module.
REVIEW: 121545
|