On Mittwoch, 20. Januar 2021 13:51:15 CET Harald Sitter wrote: > On 19.01.21 16:57, Friedrich W. H. Kossebau wrote: > > Hi, > > > > the docs of the module tell us: > > "KDEFrameworkCompilerSettings - Set stricter compile and link flags for > > KDE > > Frameworks modules." > > https://api.kde.org/ecm/kde-module/KDEFrameworkCompilerSettings.html > > > > And it has been meant that way. E.g. because extending those settings with > > more strict settings or new features would be done with other KF-specific > > requirements or policies in mind, always matching those of the current > > version (given KF & ECM are released in-sync). > > Having to take care of backward-compatibility with non-KF usage and to do > > proper documentation adds additional burden not wanted here. > > > > As convenient it is to not have to write out e.g. all the > > add_definitions( > > > > -DQT_NO_CAST_TO_ASCII > > -DQT_NO_CAST_FROM_ASCII > > -DQT_NO_URL_CAST_FROM_STRING > > -DQT_NO_CAST_FROM_BYTEARRAY > > -DQT_NO_SIGNALS_SLOTS_KEYWORDS > > -DQT_USE_QSTRINGBUILDER > > -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT > > > > ) > > that needs some other solution. > > > > For ECM/KF5 times the train has left, we need to handle those existing > > abuses. But please fix your projects now already by changing back to > > KDECompilerSettings and the manual boilerplate, so in ECM/KF6 times that > > burden is gone. > > Perhaps there should be a unit test asserting this somehow? > LXR reports `247 occurences found.` so this seems a fairly wide spread > issue :( > > Perhaps hardcode a list of all cmake project names that are frameworks > in ECM and then test that the settings are only used with one of them? > Just an idea.
How about we try to come up with an alternative solution for what looks like a wide-spread demand for centrally maintained high-quality compiler settings instead then? That might also make any kind of enforcement to not use this outside of Frameworks unnecessary :) Regards, Volker
signature.asc
Description: This is a digitally signed message part.