Am Montag, 14. Februar 2022, 16:32:57 CET schrieb Albert Astals Cid:
> It introduces code breaking defines, some of them even of questionable
> benefit for an application like QT_NO_KEYWORDS
>
> I don't understand how such a breaking commit was accepted.
>
> Who is going to fix all the applications in KDE to build after that?
>
> Apps that I've tried and failed:
> * okular
> * kdenlive
> * konsole
> * ktuberling
> * kgeography
>
> And i stopped tried because i was getting super sad nothing was compiling.
>
> What is the suggested solution for this? Because I don't think it makes
> sense to burn hundreds of hours just replacing signal to Q_SIGNAL and
> wrapping all the strings ever in QStringLiteral and QLatin1Char.
>
> Never require a modern ECM?
>
> unset those defines again from the application side?
>
> Something else?
Sorry to see you running into this, seems some time has passed and this
vanished from people#s memory. Guess we should have send not one, but a few
reminder emails about the new mechanims introduced at ECM 5.85.0.
TL;DR Please use
set(KDE_COMPILERSETTINGS_LEVEL 5.84.0)
before
include(KDECompilerSettings NO_POLICY_SCOPE)
For more details see
https://marc.info/?l=kde-devel&m=162893561025502&w=2
as well as
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/144
That approach was the best people could come up at the time to allow
introducing new requirements.
Cheers
Friedrich
