Summary: Use QT_NO_NARROWING_CONVERSIONS_IN_CONNECT as default flags Reviewers: dfaure Reviewed By: dfaure Subscribers: kde-frameworks-devel, kde-buildsystem Tags: #frameworks, #build_system Differential Revision: https://phabricator.kde.org/D15566
This reverts commit 6684cb99bdf408fc491e547393dbd7aac4d151f2. See https://phabricator.kde.org/D8256 for details
When building on non-glibc Unix platforms, such as Solaris, NetBSD, and Linux/musl or Linux/uclibc, multiple components of KF5 fail to build. This is because -std=iso9899:1990 is specified (for strict C90 compliance) but _XOPEN_SOURCE is not defined, so none of the POSIX interfaces are exported. I have seen this reported in at least: * kinit * kscreenlocker * plasma-workspace The attached patch resolves this issue on all our build boxes; additionally, applying it to my glibc builder did not change the already working result. BUG: 373175 Differential Revision: https://phabricator.kde.org/D8256
Summary: ECMPoQmTools will need to have the translations downloaded at configure time instead of on build time, otherwise it needs an awkward second configure. To that end we introduce a KDE_L10N_SYNC_TRANSLATIONS variable that allows it to do so. ECMPoTools will download the translations in the build directory, because cmake shouldn't touch the sources. Have it check the build directory too when the macro is called. Test Plan: Built analitza translations. Reviewers: #frameworks, cgiboudeaux Reviewed By: cgiboudeaux Subscribers: cgiboudeaux, kde-frameworks-devel, kde-buildsystem Tags: #frameworks, #build_system Differential Revision: https://phabricator.kde.org/D14569
Summary: QT_USE_FAST_OPERATOR_PLUS has been deprecated in Qt 4.8, in favour of QT_USE_QSTRINGBUILDER. The latter also covers QByteArray. Qt5 headers still supports QT_USE_FAST_OPERATOR_PLUS (at least 5.11.1), as subset of QT_USE_QSTRINGBUILDER as it was introduced in Qt4.8, but not as documented build flag. Given QT_USE_QSTRINGBUILDER is set here and thus triggers anything that QT_USE_FAST_OPERATOR_PLUS would trigger in Qt code, removing it should clean up the macro from undocumented features and thus reduce confusion. No non-Qt is known at least in KDE repos which checks this build flag otherwise, so no regression should be expected here as well. Reviewers: vkrause Reviewed By: vkrause Subscribers: kde-frameworks-devel, kde-buildsystem Tags: #frameworks, #build_system Differential Revision: https://phabricator.kde.org/D13800
Reviewers: cgiboudeaux, apol Reviewed By: cgiboudeaux, apol Subscribers: apol, kde-frameworks-devel, kde-buildsystem, cgiboudeaux, dhaumann Tags: #frameworks, #build_system Differential Revision: https://phabricator.kde.org/D10166
Summary: It's not a thing on flatpak and it makes packaging weird. Should fix https://github.com/flatpak/freedesktop-sdk-base/issues/22 Reviewers: #frameworks, cgiboudeaux Reviewed By: cgiboudeaux Subscribers: cgiboudeaux, eszlari, kde-frameworks-devel, kde-buildsystem Tags: #frameworks, #build_system Differential Revision: https://phabricator.kde.org/D13102
Summary: Otherwise we hit a weird code path on androiddeployqt. This is what the official SDK looks like anyway: ``` $ ls /opt/Qt/5.10.1/android_armv7/ bin doc include jar lib mkspecs plugins qml src translations ``` Reviewers: vkrause Reviewed By: vkrause Subscribers: #frameworks, #build_system Tags: #frameworks, #build_system Differential Revision: https://phabricator.kde.org/D12269