Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
Summary:
Now and then tagging some API as deprecated for the compiler is forgotten.
Doing this retractivitly in newer versions but using the official version
might break build setups configured to only show warnings up to a certain
version and otherwise fail a build, using -Werror=deprecated-declarations.
To allow retroactive tagging of API for compiler warnings, and showing the
official version in the warniung message, while reacting only to warning
controls for the current version where the tag is added, avoids any such
annoying experiences, without wrong version info at the same time.
Reviewers: #frameworks, #build_system, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29573
|
|
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
|
|
|
|
Test Plan: works as before for the case where it's relative.
Reviewers: cgiboudeaux, vatra, kfunk, apol, vkrause
Reviewed By: cgiboudeaux
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29524
|
|
Summary:
Instead of generating
QT.KArchive.includes = /full/path/include/KF5/KArchive
make it
QT.KArchive.includes = $$PWD/../../include/KF5/KArchive
This makes the whole install prefix relocatable after the fact,
the includes will be found based on where the .pri file ended up.
This is especially useful for Conan support, says Bogdan.
Test Plan: After make install in ECM, cd karchive/examples/helloworld && qmake && make
Reviewers: vatra, kfunk, apol, vkrause
Reviewed By: vkrause
Subscribers: ablu, kossebau, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29274
|
|
Summary:
cmake introduced a new find_package mismatch check in 3.17, but also allows
user to suppress the warning by setting a variable (Or parameter, but
require new cmake 3.17). Same technique is also used with in cmake,
e.g. FindGTK2.cmake.
Test Plan: Test with FindXCB.cmake
Reviewers: #frameworks, #build_system, apol
Reviewed By: apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D29396
|
|
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
|
|
|
|
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
|
|
|
|
Summary:
Not passing CMAKE_INSTALL_PREFIX is a weird thing to do. The test shows
"Installing in ." and some values like KDE_INSTALL_FULL_EXECROOTDIR
become "/" which is considered relative on Windows.
The test that passes /usr to CMAKE_INSTALL_PREFIX actually passes on
Windows. Pass /tmp to the other test, remove the test without prefix.
Test Plan: Passes on Linux, not tested on Windows, CI will do that
Reviewers: kossebau, apol, cgiboudeaux
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D28409
|
|
Reviewers: #frameworks, #build_system, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D28253
|
|
|
|
|
|
|
|
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:
This works with both the old and the new way of Qt's asset deployment, ie.
with Qt 5.13 and Qt 5.14.
Reviewers: apol
Reviewed By: apol
Subscribers: apol, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Maniphest Tasks: T12520
Differential Revision: https://phabricator.kde.org/D27596
|
|
|
|
With some build configurations no catgories might be registered for
a given export id.
Instead of failing hard and thus forcing to catch this situation
explicitly on the caller side, be grateful on the callee side
and just generate an empty file, so the installed file set is consistent.
GIT_SILENT
|
|
NAME_WLE might be more nice to support any people who might want to use
a dot in the base filename, but that needs newer cmake.
GIT_SILENT
|
|
Summary:
Having to manually maintain a separate copy of all the data about qt logging
categories in the categories files comes with the usual disadvantages.
The new macro ecm_qt_install_logging_categories together with the additions
of arguments DESCRIPTION & EXPORT to ecm_qt_declare_logging_category allows
to have just one place with one copy of the data, and have the categories
file automatically generated from that data, linked via the EXPORT id.
For cases not using ecm_qt_declare_logging_category, but having categories
manually defined in code, yet wanting to have info about those categories in
the installed fiel, ecm_qt_export_logging_category allows to add those data
to the system.
Test Plan:
Added unit tests work, porting of some repos created categories files whose
diff against the manually created files were only the DO_NOT_EDIT header.
Reviewers: #build_system, #frameworks, broulik, mlaurent
Reviewed By: mlaurent
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D27150
|
|
|
|
|
|
Summary:
Populate module_config with staticlib. This is needed for Qt 5.12, as
Makefiles contain the full path to the library instead of just the base
name. QMake needs to be aware of the build type. This issue was found in
KDStateMachineEditor's .pri files.
Before this patch the linker tried to link against .so files even for
static libraries.
Note: Probably not very relevenat to KDE Frameworks (since it's all
about shared libraries, but I'd like to keep the original
ECMGeneratePriFile version up-to-date)
Compare:
```
% cat kdsme-qmake-test.pro
QT += KDSMEDebugInterfaceSource
!qtHaveModule(KDSMEDebugInterfaceSource): warning("Library not found")
SOURCES += main.cpp
% qmake --version
QMake version 3.1
Using Qt version 5.9.8 in /home/kfunk/devel/build/qt5.9/qtbase/lib
% qmake .
% make
...
g++ -Wl,-rpath,/home/kfunk/devel/build/qt5.9/qtbase/lib ... -L.../lib -lkdstatemachineeditor_debuginterfacesource ...
% make clean
% env-qt5.12
% qmake --version
QMake version 3.1
Using Qt version 5.12.5 in /home/kfunk/devel/build/qt5.12/qtbase/lib
% qmake .
% make
...
g++ -Wl,-rpath,/home/kfunk/devel/build/qt5.12/qtbase/lib ... .../lib/libkdstatemachineeditor_debuginterfacesource.a ...
Reviewers: dfaure, winterz, vkrause, apol
Reviewed By: apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D26394
|
|
Summary:
Without this, in Qt 5.14 I get an android-like QQC2 theme
This used to work on Qt 5.13 so I assume that it's a regression
Reviewers: mart
Reviewed By: mart
Subscribers: apol, davidedmundson, kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D26573
|
|
Summary: Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
Reviewers: tcanabrava, apol
Reviewed By: tcanabrava, apol
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D26751
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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
|
|
Summary:
The original intention has been that by default during the build of a
library no warnings should be emitted on using own deprecated API,
as for one that has to be implemented as well as often deprecated API
is implemented using other deprecated API, so the warnings are not
helpful, and having to add lots of push/pop warnings instructions
in the code for the compiler harms readability more than it helps
ensuring to only use deprecated API where one has to.
The original intention was satisfied due to the default mechanism in the
generated export header code, where DEPRECATED_WARNINGS_SINCE if not set
defaults to DISABLE_DEPRECATED_BEFORE_AND_AT. That though breaks once
the group version of DEPRECATED_WARNINGS_SINCE is set in the build, as
this default has higher priority by design, even if the usage here only
wants to target dependency libs of the same group, not the current library.
To restore the intented default behaviour, by default
DEPRECATED_WARNINGS_SINCE is now explicitely set for the library build
itself to the EXCLUDE_DEPRECATED_BEFORE_AND_AT value, and a new macro
option allows to disable this.
Reviewers: #build_system, #frameworks, dfaure
Reviewed By: dfaure
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25589
|
|
Summary: -weXXXX errors on warning XXXX. C4996 warns on deprecated declarations.
Test Plan: Tests pass.
Reviewers: kossebau, #windows, #frameworks
Reviewed By: kossebau
Subscribers: kde-frameworks-devel, kde-buildsystem
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D25626
|
|
|
|
Systemd searches
"/usr/local/lib/systemd/user",
"/usr/local/share/systemd/user",
USER_DATA_UNIT_PATH,
"/usr/lib/systemd/user",
"/usr/share/systemd/user",
LIBDIR could be lib or lib64, so we need to be explicit here.
Reviewed on D25107
|