Re: increasing CXX_STANDARD for kdevelop

On Wednesday, 14 October 2020 13:59:17 CEST Milian Wolff wrote:
> 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?

Hmm, I thought it is but it longer seems to be the case:
  https://www.kdevelop.org/download -- "(Wanted: someone to maintain the same 
for AppImages and macOS DMG files)" ;)

Sorry, a bit out of the loop.

Greets,
Kevin


> I
> would then automate a few steps, based on the experience I have with
> AppImage generation in docker in heaptrack and hotspot.
> 
> Cheers


-- 
Kevin Funk | [email protected] | http://kfunk.org

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQ2TvpfY5VykH05KZnGTPVrE8rOXQUCX4butQAKCRDGTPVrE8rO
XYGHAJ9GF2UPnNXEniWMImG1IkKfktqQpQCdF+07ttr92LGDONiDNJp0pA9Rqbo=
=eE1W
-----END PGP SIGNATURE-----