| Age | Commit message (Collapse) | Author |
|---|
|
By using ${CMAKE_COMMAND} we make sure the current cmake is used,
instead of relying that some cmake can be found in the path
|
|
I hit this issue while building Kaidan using craft,
outside of the KDE Android docker container. Hopefully this is the
correct way to fix it.
|
|
These are the variables that cmake will pass onto itself when doing a
try_compile, we need that because otherwise when trying to find iconv it
will issue a try compile, won't pass CMAKE_ANDROID_API so it will
default to 21 (instead eg the 28 we had given it) and the try_compile
will fail because android libc only has iconv after API 28
|
|
|
|
|
|
- We don't need the Threads target workaround anymore, that breaks the
build with Qt6 even.
- The Gradle wrapper shipped with Qt is no longer installed as executable,
so we need to run this in sh explicitly.
- Qt6 uses a different Android Gradle plugin version (not to be confused
with the Gradle version), which we need to make available for the
configure_file() call on the build.gradle file.
With this most Framework modules build against Qt6 here.
|
|
The relevant issue is only fixed in 23
|
|
I was seeing `error: No such remote 'origin'` in the cmake output.
This commit avoids hardcoding `origin` as the upstream URL and instead
uses the `git rev-parse @{u}` to get the configured upstream.
As a follow-up we may want to check if this should be executed by default,
but for now this fixes a warning that I'm seeing with various projects.
|
|
And the generated html looks more correct
|
|
GIT_SILENT
|
|
This fixes spurious differences after a roundtrip through Google Play,
breaking change detection and thus triggering unnecessary metadata
updates.
|
|
This considerably simplifies comparing our data with that retrieved from
Google Play for automatically syncing metadata.
|
|
Qt maps it this way
|
|
|
|
This relies on the apparently predominant naming pattern for those files,
those of our apps not using this often do not seem to have an appropriate
file (512x512 png) to begin with.
Explicit override is also possible, by the already existing mechanism of
putting a file with the right name into the fastlane/ source directory.
Having the icon included here will allow it to be automatically synced to
the Play store.
|
|
Instead, restore their plain text fallback output that we used to have
already prior to enabling rich text support.
|
|
Contrary to the comment those exist (e.g. ul, ol), this just wasn't noticed
as due to the script-enforced formatting those always contain some spaces.
This resulted in different structures between English and translated
description texts. With this change all language variants show the same
structure.
|
|
We have to handle both entirely missing top-level elements and arbitrarily
incomplete sub-elements in the description body.
Until now we were just kept those gaps, resulting in missing titles or
incomplete descriptions. F-Droid didn't complain about that, but Google
Play does. This fixes e.g. Itinerary's metadata for de and ru.
|
|
This is likely still not complete, but with this at least most of
Itinerary's metadata translations are accepted during upload to the
Google Play store (the remaining ones are rejected for different reasons).
F-Droid seems considerably less picky about this, and works with either
form.
|
|
CMake >= 3.0 supports bracket comments, and the reStructuredText
integration code in sphinx/ext/ecm.py already supports extracting
the docs from a bracket comment instead.
Editing documentation without leading line comment markers is more simple,
e,g. when reflowing text over lines.
With ECM meanwhile requiring CMake 3.5 now it is possible to switch
(and thus follow also the approach used by cmake itself).
NO_CHANGELOG
|
|
|
|
We need this to pass the --release option for binary factory release
builds.
An alternative approach would be to set that here automatically depending
on the CMake build type. Since that however ends up producing unsigned and
thus not immediately usable APKs (or would need a whole set of extra
arguments for proper signing) I'm not sure whether that's most convenient
for local use.
|
|
This is no longer needed now that the metadata happens as part of the
build process rather than afterwards on the signing system. This allows
us to simplify the code here a bit.
|
|
|
|
Those occur for example in Marble.
|
|
This adds support for image assets not represented in the appstream data,
such as the banner image for the F-Droid app, and it allows to override
appstream screenshots by local ones. The latter is e.g. used by KTrip
which provides Android-specific screenshots that way.
|
|
This should improve the alignment issues currently seen in bullet point
lists that we use frequently in the description text.
|
|
BUG: 424392
|
|
This makes use of the CMake 3.19 DEFER command to list all MODULE
targets after processing the toplevel CMakeLists. This allows us to
collect required dependencies of all plugins without changes to the
application. For example, this will fix Okular not including Poppler
because it is only linked from the plugin, thus not being able to
actually read PDFs.
|
|
|
|
Locally unlink() seems to work just fine on non-existent files, but on
binary factory that seems to be different for some reason.
|
|
This matters when reusing output folders (as binary factory does for
example), as we then retain outdated screenshots and just keep adding
files to an already existing fastlane archive.
|
|
Also, check for the HTTP status code, so we don't end up with 404 error
messages in image files here.
|
|
This should fix the Okular build failure on binary factory.
|
|
This broke the builds for apps not having categories in their appstream
files.
|
|
This is currently done on the signing machines as part of the F-Droid
nightly pipeline, but should rather happen as part of the build process
in the future.
Compared to the binary factory script this has a few extensions already:
- Besides recovering information from APKs we can now consume appdata
files directly, or scan the entire source dir.
- Screenshots from appdata files are downloaded.
- The 'x-test' language is ignored.
- Donation and translation information are added.
- Add links to the source code repository, if we can determine that.
The result is put into a single archive per APK, so we can easily transfer
that to the signing machine via Jenkins alongside the APK.
|
|
This matters for libraries in the same repository as the application that
also have an AAR that needs to be integrated, as well as QML plugins. For
this to work we need to consider the build directory as a search prefix,
and produce the exact directory layout there that androiddeployqt expects.
For libraries this is then almost transparent for the application build
system, the only thing that needs to be taken care of manually is putting
the corresponding -android-dependencies.xml file into the right place in
the build dir as well. A macro wrapping that might be an option to
centralize that logic here as well in the future.
For QML plugins this is transparent if you have them set up to work without
installation already anyway, otherwise that setup has to be done for this
to work.
Example: https://invent.kde.org/pim/itinerary/-/merge_requests/28
https://invent.kde.org/frameworks/knotifications/-/merge_requests/12 would
presumably also need this (not tested yet).
|
|
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 document --android-platform parameter
|
|
Also pass along these values to androiddeployqt
|
|
Qt adds the Android ABI to the suffix there unconditionally, without also
adjusting CMAKE_FIND_LIBRARY_SUFFIXES accordingly, breaking find_library()
for things built that way. Unfortunately we can't just set this in our
toolchain file, as CMAKE_FIND_LIBRARY_SUFFIXES is overwritten by CMake
after evaluating the toolchain file. So we need to use the variable_watch
hack for this here, thanks to Aleix for the idea.
With this, find_library() works for both suffixed and un-suffixed libraries
again, such as Poppler built with or without Qt support.
|
|
|
|
|
|
Summary:
This allows `make create-apk` to directly write the APK to /output instead of the cp-with-prefix step in /opt/helpers/create-apk. It's also useful for manual development builds where one would need to copy it to some output location manually or for CI setups that expect the output in a certain location.
If ANDROID_APK_INSTALL_DIR is not set the current behaviour is kept.
Reviewers: #frameworks, #android, apol, vkrause
Reviewed By: #android, apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29631
|
|
Summary: Makes them easier to use afterwards.
Test Plan: Tested locally
Reviewers: #android, #frameworks, nicolasfella
Reviewed By: nicolasfella
Subscribers: vkrause, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29079
|
|
Summary:
This changes from using the toolchain file provided by CMake to using the
one provided by the NDK, as even recent CMake can't build successfully
with r20. However this is a rather invasive change, the interface and
variable names differ.
The Qt 5.14 changes are less risky, as most of this is parallel to the
support for older versions.
Test Plan: Local builds with 5.14/r20, 5.14/r18 work, the Docker SDK isn't tested yet, and there's some remaining issues with 5.13 and older NDKs I don't fully understand yet. The resulting apks with 5.14 install, and work for QQC2 content, but fail to start Kirigami apps.
Reviewers: apol
Reviewed By: apol
Subscribers: flherne, apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Maniphest Tasks: T12520
Differential Revision: https://phabricator.kde.org/D26749
|
|
Summary: The APK output path changed at some point
Test Plan: can do make install-apk-appname again
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D26402
|
|
|
