[sysadmin/release-tools/frameworks/5.0] /: KF5: auto-increase QT_DISABLE_DEPRECATED_BEFORE when upgrading the min Qt version

[Friedrich W. H. Kossebau]

Am Sonntag, 27. Oktober 2019, 11:26:51 CET schrieb David Faure:
> On dimanche 27 octobre 2019 03:07:01 CET Friedrich W. H. Kossebau wrote:
> > Am Freitag, 25. Oktober 2019, 00:35:46 CET schrieb David Faure:
> > > On jeudi 24 octobre 2019 22:24:55 CEST Friedrich W. H. Kossebau wrote:
> > > > BTW, we want to also set
> > > > 
> > > >     -DQT_DEPRECATED_WARNINGS_SINCE=0x060000
> > > > 
> > > > otherwise the deprecations done with QT_DEPRECATED_VERSION in Qt's API
> > > > will
> > > > not emit warnings, because QT_DEPRECATED_WARNINGS_SINCE defaults to
> > > > QT_DISABLE_DEPRECATED_BEFORE if set.
> > > 
> > > Oh, good to know. Done now for all of KF5.
> > 
> > And the same would need to be done also for the KF variant, i.e. setting
> > 
> >     -DKF_DEPRECATED_WARNINGS_SINCE=0x060000
> > 
> > otherwise the use of KF_DISABLE_DEPRECATED_BEFORE_AND_AT will also result
> > in warnings for API deprecated only in newer versions.
> 
> Hmm, true.
> 
> > Quite some explicit setup. But I made ECMGenerateExportHeader follow what
> > Qt does, as consistency rules here IMHO.
> > 
> > Both QT_DEPRECATED_WARNINGS_SINCE & DKF_DEPRECATED_WARNINGS_SINCE could be
> > though set via KDEFrameworkCompilerSettings perhaps, that would match what
> > is done for -Wzero-as-null-pointer-constant already.
> 
> That would make sense, good idea. I didn't want the DISABLE stuff to come
> from ECM, so we keep some control over it (and it's a good thing I did, see
> commit dd98b2b7175b in kimageformats)
> 
> But for warnings, not much harm can happen, so that's a good idea.

Created a patch to do so: D24990

Though leaving applying this patch to you, as you seem to have the tools 
prepared for mass-handling of KF repos, to remove the
    -DQT_DEPRECATED_WARNINGS_SINCE=0x060000
line again from all those now that it would be duplicated :)

Cheers
Friedrich