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. HS