Age | Commit message (Collapse) | Author |
|
Use the variable we just created to look up Qt5.
Remove debug warning.
|
|
|
|
Summary:
Refactor the apk-generating code into a separate function, in views of
eventually even make it a module.
It also changes so that if no APK dir is specified, a generic dummy one is
used. Useful for proofs of concept.
Test Plan: Built kate, got kate and kwrite apks
Reviewers: #frameworks, #build_system, vkrause
Reviewed By: vkrause
Subscribers: vkrause
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12150
|
|
Summary:
Back in the KDE Edu sprint, we decided we need such a check, otherwise
you get rather frustrated when the application isn't started. A patch to
androiddeployqt was submitted but rejected by the maintainer.
https://codereview.qt-project.org/#/c/207941/
Test Plan: kate doesn't build if we don't pass Q_DECL_EXPORT, builds if we do.
Reviewers: #frameworks, #build_system, vkrause
Reviewed By: vkrause
Subscribers: vkrause, vatra, aacid
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D12120
|
|
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: qmlimportscanner fails when provided symlinks, so work around that.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D11181
|
|
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:
This is needed for NDK headers to work correctly, and is the same as the
CMake code in the NDK does.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: apol, #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10777
|
|
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:
Those affect policy propagation and search path order for relative
includes in CMake code, none of which is needed here. This silences
a ton of warnings with CMake 3.10.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10602
|
|
Summary: This allows e.g. KArchive to find zlib correctly.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10601
|
|
Summary:
This allows easy platforms checks in CMake files, and is the same the
CMake files shipped by the Android SDK use.
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10600
|
|
Summary:
ANDROID_TOOLCHAIN is "x86" there, while the include path we want is
"i686-linux-android". ANDROID_COMPILER_PREFIX has that value in all
cases (for ARM both are the same, so nothing changes there).
Reviewers: #build_system, apol
Reviewed By: apol
Subscribers: apol, dfaure, #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10599
|
|
Summary:
For ARM it's not necessary, but when building for a x86 tablet I had to
set ANDROID_TOOLCHAIN=x86 while gcc/g++ are prefixed with
i686-linux-android.
i.e. the path is android-ndk-r10e/toolchains/x86-4.9/prebuilt/linux-x86_64/bin/i686-linux-android-g++
Test Plan: cmake picks up the right compiler for me now
Reviewers: apol, mart
Reviewed By: apol
Subscribers: #build_system, #frameworks
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D10462
|
|
Summary:
Without this i get
In file included from /home/tsdgeos/Android/Sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/bits/stl_algo.h:59:0,
from /home/tsdgeos/Android/Sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/algorithm:62,
from /home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtCore/qglobal.h:109,
from /home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtGui/qtguiglobal.h:43,
from /home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtWidgets/qtwidgetsglobal.h:43,
from /home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtWidgets/qapplication.h:43,
from /home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtWidgets/QApplication:1,
from /home/tsdgeos/devel/kde/ktuberling/main_mobile.cpp:11:
/home/tsdgeos/Android/Sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdlib:72:20: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
^
compilation terminated.
Reviewers: apol
Reviewed By: apol
Subscribers: apol, vkrause, #frameworks, #build_system
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D9899
|
|
Summary:
We were using a link.txt file that cmake used to generate, on newer cmake
versions it doesn't anymore.
Instead use readelf, much like androiddeployqt does, to extract the
depenencies.
Catch: It relies on having all the binaries being at the same subdirectory,
which is the default in ECM since not long ago.
Test Plan: Build kirigamigallery with it
Reviewers: #frameworks, #build_system, aacid
Reviewed By: aacid
Subscribers: mart
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D8173
|
|
|
|
Ninja chokes on the $
|
|
Otherwise when trying to build with the newest Qt/android toolchains it
fails
Differential Revision: https://phabricator.kde.org/D6875
|
|
Differential Revision: https://phabricator.kde.org/D6876
|
|
Fix typo
|
|
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
|
|
set ECM_ADDITIONAL_FIND_ROOT_PATH the same as
CMAKE_PREFIX_PATH if not specified explicitly
from the commandline
reviewed-by:apol
|
|
|
|
Summary:
Currently (since 123d0d14017a25fb387efd8fe3c2c1323f9c3815) any
find_library() and find_path() calls look both at the host and the toolchain
paths, which often results in includes and/or libraries wrongly being picked
up from the host system, which then results in a failed build.
CMake config files have always been also looked for on the host, which
most often also is not wanted and resulting in a failed build.
This patch fixes that by changing the mode for finding libraries,
includes & packages to ONLY (again), as also recommended in the
cmake-toolchains documentation.
While before CMAKE_PREFIX_PATH was recommended to let cmake e.g.
discover the Qt5 for Android libs, this patch wants a custom
variable ECM_ADDITIONAL_FIND_ROOT_PATH to be used instead.
Reason is that CMAKE_PREFIX_PATH would be subject to the root
handling, while here instead the root paths themselves are
wanted.
This patch does not add backward compatibility for still passing
the Qt5 install prefix via CMAKE_PREFIX_PATH, as there are not
that many users known yet and the old code did not work for many
anyway, so the extra code hassle is not worth it. Instead the few
build instructions would need to be updated (and should ask to use
latest ECM in any case).
Test Plan:
Building Marble now works without trying to use stuff from the
host system.
Reviewers: #frameworks, #gcompris, #minuet, mutlaqja, sandsmark, cordlandwehr, nienhueser, apol
Reviewed By: cordlandwehr, nienhueser, apol
Differential Revision: https://phabricator.kde.org/D3646
|
|
Reviewers: #frameworks, cordlandwehr, apol
Reviewed By: apol
Differential Revision: https://phabricator.kde.org/D3732
|
|
|
|
REVIEW: 128780
|
|
GIT_SILENT
|
|
Explains how to install and sign apks
REVIEW: 128634
|
|
Needed for many unit tests to add them to APK files.
REVIEW: 128175
|
|
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
|
|
The only reason why it used to work, is because all libraries we're including,
provide *Config.cmake files, which don't respect this setting.
REVIEW: 126896
|
|
Makes sure there isn't old stuff still there, it didn't save much time to
keep the files around anyway.
|
|
* 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.
|
|
|
|
QtCore/qsystemdetection.h sets the define Q_OS_ANDROID based on having
ANDROID defined. Hence, adding the ANDROID define allows applications to
use the Q_OS_ANDROID for ifdef'ing.
REVIEW: 125183
|
|
|
|
|
|
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
|