Age | Commit message (Collapse) | Author |
|
Continuation of commit 4e47b053c9d799.
All unittests still pass.
|
|
- 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.
|
|
|
|
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
|
SunOS and variants (Solaris, OpenSolaris, illumos, etc al.) do not need a separate library for inotify.
|
|
This doesn't make all these modules actually work with Qt6 yet, but it
prevents them from unconditionally pulling in Qt5 in a Qt6 build.
This is useful in order to even be able to pass a CMake run to the
point one can port, test and debug the rest.
|
|
|
|
PKG_CONFIG_SYSROOT_DIR only applies to -I and -L flags, so pkg-config
does not prepend CMAKE_SYSROOT when cross-compiling unless you pass
--define-prefix explicitly. Therefore we have to manually do prepend
it here when cross-compiling.
See https://gitlab.kitware.com/cmake/cmake/-/issues/16647#note_844761.
With this change I no longer get errors related to wayland.xml when
cross-compiling KWaylandServer.
|
|
|
|
When cross-compiling QT_INSTALL_BINS contains binaries for the target
system that can't be used during the build. Instead use QT_HOST_BINS
which contains the Qt build tools for the current system.
|
|
Plain freedesktop.org 302-redirects to www.freedesktop.org.
Also, fixes a warning during CMake generation step in plasma-desktop.
See https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/572
|
|
The proximate problem is that the Python Module generator cmake script
has started failing for people with Python 3.10, which a CMake backtrace
pointing into FindPythonModuleGeneration.cmake with an error of the form
"The max python version in PythonModuleGeneration must be updated."
At least one distro has addressed this by simply patching out modules
that happen to use this CMake module [1].
From what I can tell and the testing I've done, the cause is pretty
simple: The CMake script attempts to find the best Python 3 version by
starting from an impossible version and working backwards until it finds
a version that is installed.
As a sanity check, if the "impossible" version is actually present, it
aborts. But this appears to be just a sanity check, and not any sort of
guard against buggy version handling code later.
While the best fix is probably to start from a known *good* version and
move up until we stop finding better versions, there's problems here
(e.g. a user with 3.6 and 3.8 installed would fail to see 3.7 and so be
left with 3.6 as the "best" match), so I opted just to increase the max
version significantly, and improve the documentation as to what's
happening and whether it is safe to repeat the step again later.
[1]: https://bugs.gentoo.org/746866
|
|
|
|
|
|
GIT_SILENT
|
|
|
|
There is a chance it's going to be used in Solid, and possibly KIO.
Other exiting modules were used as templates while writing this.
|
|
CMake 3.14 ships a module with compatible variables.
|
|
- Remove deprecated version checks
- Use VERSION_GREATER_EQUAL
|
|
pkg_search_module() is only useful when the pkgconfig file may have different names.
|
|
|
|
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
|
|
The code argument has been deprecated in favor of public-code and
private-code options.
In general, it is highly advised to use the private-code option, but we
cannot do it because it will break the ABI.
|
|
This is a slightly modernized version of Pino's original implementation
found in KF5 and Plasma.
|
|
We have identical copies of this in kinit, kwin, ksysguard and
powerdevil. This makes it a natural candidate for inclusion in ECM.
|
|
It is based on the one that can be found in KWin.
Several KDE projects already use libepoxy (KWin and KDeclarative).
|
|
|
|
Have the C counterpart take care of the C files and the C++ for the C++
files.
Don't forget to skip the server C implementation.
|
|
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).
|
|
I had reuse installed but it wasn't being found. Now it is.
|
|
|
|
Besides finding Gradle from QtAndroidExtras and thus avoiding the usual
way of the Android world of distributing that (a copy in your source code),
it provides macros to generate and install Android AARs. Those are needed
for libraries that have a non-trivial Java component on Android, e.g.
needing a manifest fragment or having a dependency on other Java libs.
This file has been copied to a few places meanwhile, so centralizing this
in ECM makes sense.
|
|
When creating a library or executable, several source files are combined
into a binary artifact that has an outbound license of its own. This test
generator allows to check if the combined source files are compatible
with the desired outbound license.
Requirements for using these tests:
- input source files must contain the SPDX-License-Information tag
- python3 must be available
- the "reuse spdx" tool must be available
|
|
|
|
An intended use case is to generate client-side and server-side code for
protocols shipped in the wayland-protocols package with qtwaylandscanner.
|
|
it only updates the database iff there's new files and is specifically
meant for post-install invocation. since cmake only installs files when
they actually changed this effectively turns repeated cmake --install
calls noop as far as database updates are concerned
this stops all sources with mimetype definitions from rebuilding the
mime database on every install even when nothing changed. it saves
literal seconds every install call
-n was introduced in 1.4 which is like 6 years old and there are no
pratcically relevant distribution versions around with older versions
|
|
|
|
This is useful if a library intends to reparse the original wayland.xml
file instead of using the pregenerated headers.
|
|
Png2Ico provides lower quality icons compared to icoutils as png2ico
predates the current icon standard.
Still lloking for png2ico prints
* Png2Ico, Executable that converts a collection of PNG files into a Windows icon file, <https://www.winterdrache.de/freeware/png2ico/ or https://commits.kde.org/kdewin>
which confuses new users.
|
|
Without this simple space, FindTaglib doesn't appear on
the generated ecm-find-modules.7.html page.
|
|
Based on https://phabricator.kde.org/D21695
Several KDE projects use taglib, so we really need to provide a proper
find module in ECM.
AFAIK taglib-config should not be portable, so we don't try to
run it on WIN32. See also:
https://invent.kde.org/network/kio-extras/-/commit/548f525f4308810888c85f42a570139029c40618
|
|
|
|
Test Plan: KF modules configure build as before, same some apps.
Reviewers: #frameworks, #build_system, cgiboudeaux
Reviewed By: cgiboudeaux
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29097
|
|
Summary: Tells cmake not to automoc certain files that don't need it, which would become a big fuss on the cmake output.
Test Plan: No warnings
Reviewers: #build_system, #kwin, #frameworks, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D28900
|
|
When PyQt5 is compiled with SIP 5, the sip files are installed to ${python-site-packages}/PyQt5/bindings, so search for them there too.
This doesn't add support for compiling KF5 bindings themselves with sip5, that requires more work.
Differential Revision: https://phabricator.kde.org/D25972
|
|
Summary: Change transport protocol from http to https
Reviewers: apol, cgiboudeaux
Reviewed By: apol, cgiboudeaux
Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25753
|
|
Summary: Correct spelling in extra-cmake-modules comments.
Reviewers: apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25752
|
|
When using the Emscripten toolchain, there is no library linkage
necessary (there is no library) and the system include search paths
provide EGL headers.
Reviewed By: vkrause
Differential Revision: https://phabricator.kde.org/D24182
|
|
|
|
Summary: Instead of passing the data from stdin, pass the path, this way if there's an error wayland-scanner will be able to tell us the file and line where it's failing.
Test Plan: Built kwayland and kwin with it
Reviewers: #kwin, #frameworks, zzag
Reviewed By: #kwin, zzag
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D20105
|