D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in kactioncollection.h:314
> Okay, so "QT_MOC_COMPAT" is still a (just undocumented) thing, and thus something we should use for deprecated signal/slots then as before, right?
> 
> Had now another look based on your info, and found that the magic to map 0x10 onto 0x1 happens in the getter of the method attributes:
> 
>   int QMetaMethod::attributes() const
>   {
>       if (!mobj)
>           return false;
>       return ((mobj->d.data[handle + 4])>>4);
>   }
> 
> So that mystery seems solved :)
> 
> For adding deprecation attributes via _DEPRECATED to signals, yes, would agree to do this consistently then, following your argumentation. Will add this to the howtodeprecateallkindsofapi text I yet have to write, so far delayed to first gather experience.

Just remembered though: seems that Qt code itself no longer uses QT_MOC_COMPAT? At least I had no hits for actual usages in Qt classes when searching in my local Qt headers, via code.woboq.org or github search, there only for the old unsplit qt repo (which once made me think this is a Qt3 relict).

And given the `#ifndef QT_NO_DEBUG` does this warning land in normal Qt builds? (sorry, not build Qt in a decade). 
till have to test with my openSUSE TW, will do later today.

REPOSITORY
  R263 KXmlGui

BRANCH
  deprecatedapi

REVISION DETAIL
  https://phabricator.kde.org/D24466

To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191014/de747fba/attachment.html>