On Monday, 27 April 2020 14:53:32 CEST Friedrich W. H. Kossebau wrote: > 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 :) >
The reason Quick Charts is using C++14 is that I seem to remember that being the minimum required version for Frameworks. But apparently I was mistaken, might have been me mixing up Plasma and Frameworks requirements. > > 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 :) Personally, I'd be in favour of ramping up required C++ version support in light of the requirement of C++17 for Qt 6. So require 14 now, require 17 once Qt 6 is out. That way you're taking care of one bit of the transition before Qt 6 actually hits. Note also that Qt 5.14 already stopped supporting GCC <5 [1] (which is the version that supports C++14 fully) and even for 5.12 GCC 5 versions are better supported [2]. - Arjen > > Cheers > Friedrich [1]: https://codereview.qt-project.org/c/qt/qtdoc/+/288825 [2]: https://doc.qt.io/qt-5.12/linux.html
