Am Mittwoch, 6. November 2019, 14:14:41 CET schrieb David Edmundson:
> I just found a slight issue when using _DEPRECATED_SINCE.
>
> If one of two overloaded Q_SIGNALS is deprecated, clazy will blindly
> port the signal without an overload as to the compiler only one signal
> exists. This then gives a compilation error at a distro/CI level.
Any chance this is about KGamma and you ran clazy with a Qt 5.14 copy locally?
In that case, you rather ran into this (ab)use of the visibility control:
--- 8< ---
add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x060000)
--- 8< ---
Because QComboBox has this (not sure why "5, 15", possibly because perhaps
post 5.14.0):
--- 8< ---
#if QT_DEPRECATED_SINCE(5, 15)
QT_DEPRECATED_VERSION_X(5, 15, "Use textActivated() instead")
void activated(const QString &);
QT_DEPRECATED_VERSION_X(5, 15, "Use textHighlighted() instead")
void highlighted(const QString &);
#endif
--- 8< ---
Given above setting, both clazy and your compiler did not see the overload
locally with Qt 5.14.x, and all looked good. While KDE CI has Qt 5.13/5.12
where this visibility protection does not exist, so the compiler still sees
the overload and throws up.
I have warned about the use of 0x060000 with *_DISABLE_DEPRECATED_BEFORE* ,
please read https://marc.info/?l=kde-devel&m=157190321318565&w=2
This here then should be another proof why that warning made sense.
So here repeating the recommendation done by a few, which project maintainers
should pick up:
Set *_DISABLE_DEPRECATED_BEFORE* to the version of Qt/KF which is
the minimum required version.
To automate the latter in case of min dep version bumping,
ECMGenerateExportHeader comes with a utility method to get the hex number from
the min version:
--- 8< ---
ecm_export_header_format_version(${QT_MIN_VERSION} # x.y.z
HEXNUMBER_VAR qt_min_version_hexnumber # var getting 0xXXYYZZ
)
add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=${qt_min_version_hexnumber})
--- 8< ---
Cheers
Friedrich
