Requiring ECM 5.85 makes apps stop compiling

[Albert Astals Cid]

El dilluns, 14 de febrer de 2022, a les 16:53:42 (CET), Christoph Cullmann (cullmann.io) va escriure:
> On 2022-02-14 16:32, Albert Astals Cid wrote:
> > 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?
> 
> Hmm,
> 
> isn't the reason they use
> 
> include(KDEFrameworkCompilerSettings NO_POLICY_SCOPE)
> 
> and this enforces the above stuff that makes sense for libraries (as 
> e.g. without the QT_NO_KEYWORDS
> they easily clash with stuff from e.g. LLVM headers like I had at work).
> 
> I would assume if one just removed this, the more relaxed
> 
> include(KDECompilerSettings NO_POLICY_SCOPE)
> 
> won't cause these issues.
> 
> But I might be wrong.

Yes, you are wrong.

These defines were always present in KDEFrameworkCompilerSettings now they have been added to KDECompilerSettings and enabled if you require ECM 5.85 or newer.

Cheers,
  Albert

> 
> Greetings
> Christoph
> 
> > 
> > Cheers,
> >   Albert
> 
>