increasing CXX_STANDARD for kdevelop

[Milian Wolff]

On Mittwoch, 14. Oktober 2020 13:13:39 CEST Kevin Funk wrote:
> On Wednesday, 14 October 2020 12:41:20 CEST Milian Wolff wrote:
> > On Mittwoch, 14. Oktober 2020 12:36:58 CEST Kevin Funk wrote:
> > > On Wednesday, 14 October 2020 11:28:17 CEST Milian Wolff wrote:
> > > > On Mittwoch, 14. Oktober 2020 06:57:15 CEST Igor Kushnir wrote:
> > > > > On 2020-10-13 23:36, Milian Wolff wrote:
> > > > > > Hey all,
> > > > > > 
> > > > > > I'd like to increase the CXX_STANDARD for kdevelop, seems like we
> > > > > > are
> > > > > > still
> > > > > > compiling with `-std=gnu++11`. Any objections to raise this to
> > > > > > `-std=c++14`?
> > > > > > 
> > > > > > And, actually, while at it - I would personally even prefer to
> > > > > > jump
> > > > > > straight ahead to `-std=c++17`. Any objections to that?
> > > > > > 
> > > > > > I rarely have time for KDevelop, but whenever I do take the time
> > > > > > I'm
> > > > > > put
> > > > > > off by the (imo) archaic C++ support we have :) C++17 is a lot of
> > > > > > fun,
> > > > > > esp. with `if constexpr` and some other utilites.
> > > > > > 
> > > > > > Cheers
> > > > > 
> > > > > Hi Milian,
> > > > > 
> > > > > I'd love that change too. Never had a chance to practice C++17 yet.
> > > > > I
> > > > > can see two downsides though:
> > > > > 
> > > > > 1. If the KDE Frameworks and the majority of KDE applications are
> > > > > mostly
> > > > > tested with C++11 (not sure about that), then there might be
> > > > > compatibility issues and bugs exposed by switching KDevelop to a
> > > > > different C++ standard.
> > > > 
> > > > From personal experience, I would say this is a non-issue. The ABI is
> > > > independent of the compiler version being used e.g.
> > > > 
> > > > > 2. Some of the compilers KDevelop aims to support may not support
> > > > > C++17
> > > > > perfectly. We'll need to specify which versions of which compilers
> > > > > should be able to build KDevelop, then use standard feature support
> > > > > tables like this -
> > > > > https://en.cppreference.com/w/cpp/compiler_support#cpp17 - whenever
> > > > > we
> > > > > try out a new feature.
> > > > 
> > > > Right, does anyone know a table of compiler versions as shipped with
> > > > the
> > > > major distributions? I seem to remember I once saw something like
> > > > that.
> > > 
> > > Heya,
> > > 
> > > Repology.com maybe?
> > > 
> > > E.g.:
> > >   https://repology.org/project/clang/versions
> > 
> > That looks good - thanks!
> > 
> > Based on the feedback I got so far it seems like we should be able to
> > update to C++17. Based on the question below I'll then make that step in
> > the next days.
> > 
> > > Also check whether the compilers on the CentOS image we're using for
> > > AppImage building has proper C++17 support. Though I'm sure there's also
> > > a
> > > more recent devtoolset one can use on CentOS to overcome these issues
> > > (haven't checked it).
> > 
> > Where do I find documentation on the AppImage build setup for KDevelop?
> 
> All here:
>   https://invent.kde.org/kdevelop/kdevelop/-/tree/master/appimage
> 
> Though FLHerne was in the process of updating to CentOS 7 at least (we're @
> CentOS 6.10 right now). Not sure that was successful, Francis?

Ah, thanks!

Is this integrated into craft/CI anywhere, or can I hack on this at will? I 
would then automate a few steps, based on the experience I have with AppImage 
generation in docker in heaptrack and hotspot.

Cheers

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20201014/4fe24ef3/attachment.sig>