Am Montag, 27. April 2020, 00:45:41 CEST schrieb David Faure: > On Sunday, April 26, 2020 5:30:37 PM CEST Friedrich W. H. Kossebau wrote: > > Hi, > > > > I just saw that at least kimageformats, knewstuff & kquickcharts all set > > this: set(CMAKE_CXX_STANDARD 14) > > > > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > > > Which ignores a bit that so far C++11 has been the minimum standard > > officially supported in/by KDE Frameworks (by mainly following what Qt 5 > > supports). > > > > Compare also the current text of the policy > > "Frameworks compiler requirements and C++11": > > --- 8< --- > > The following minimal compiler versions are supported by KDE Frameworks: > > * GCC 4.8 > > * Clang 3.3 > > * VS2013 (MSVC12) > > > > This means all of the C++11 standards can be used. > > --- 8< --- > > * https://community.kde.org/Frameworks/ > > Policies#Frameworks_compiler_requirements_and_C.2B.2B11 > > > > What to make of this? Might it be the time to raise the bars a bit, and > > how > > much? Surely the lower limit is what the oldest Qt version currently > > supported by KDE Frameworks claims to support: > > https://doc.qt.io/qt-5.12/supported-platforms.html > > > > Should we go above this? > > Or should kimageformats, knewstuff & kquickcharts be fixed to use C++11 > > only again? > > > > No own opinion, so far only stumbled over what seems a policy breakage. > > The goal was to align with the requirements of the Qt version we require. > > But it's hard to know if anyone is actually using gcc 4.8 to build the > current version of KF5. One way to find out is to... do nothing. Leave the > above as is and see if anyone actually complains that it doesn't match our > promise.
For reference, the CMAKE_CXX_STANDARD 14 is present in those modules... KQuickCharts: since KF 5.65 (== addition of module) KNewStuff: since KF 5.69 KImageFormats: since KF 5.70 So relatively new, meaning the field observation phase only just began :) > This isn't however a green light for doing this everywhere, not until we > wait multiple months for feedback. Otherwise the porting effort (down to > C++11) will be huge. One personal motivation to ask was the hope that we could go C++14 across all KF modules now. Not needing to support C++11 anymore, but relying on C++14 deprecation tagging features would simplify ECMGenerateExportHeader code and, what triggered me here, make it simple to extend version-based deprecation tagging also for enumerators. Guess I am out of luck then for now, or have to post-pone the feature :) Cheers Friedrich