On ECMDeprecationSettings

[Friedrich W. H. Kossebau]

Am Dienstag, 28. Juni 2022, 13:12:33 CEST schrieb Aleix Pol:
> I wonder if it would make sense to have the ECMDeprecationSettings
> calls in KDEFrameworkCompilerSettings rather than in each separate
> framework in a copy-paste manner.

The calls are more-pr-less replacing the current direct add_definitions calls 
with nicer-to-human calls using the new macro. So the principle of all the 
repeated instructions is as before (module the now needed extra 
ECMDeprecationSettings include. No change there.

I had also pondered whether things could be deduplicated somehow while 
touching things, but my thoughts against are:

a) While settings in many modules are the same, often they are not. And at 
least one module needs lower Qt visibility level, supporting that exception 
needs extra code which adds complexity (and we lack cmake coders in KDE, just 
got a reply today what translated to me as "too lazy to write proper cmake 
code", no idea how to social-engineer people here).

b) Upgrading the min levels is a thing which needs investigation module-by-
module. Requiring the persons doing the level bump to have to handle all the 
dozens KF modules in one go will be a task too few have time slots for I 
guess, so no-one might do that. Allowing to bump individually allows to 
distribute the work by time & persons.

In general, when it comes to deduplication in CMake code of KDE Frameworks 
modules, there is big potential in many places, so many patterns which are now 
stable and which could be reduced into CMake macros for simple developer-
facing KF cmake code. But no time and energy myself here currently.

For this deprecation handling setting alone, at least I have no good idea how 
to simplify without adding cost at other places, like above mentioned. But 
others might, so please share your ideas.

Cheers
Friedrich