Moving KWayland to frameworks

[Kevin Ottens]

On Thursday 10 December 2015 08:02:49 Martin Graesslin wrote:
> On Wednesday, December 9, 2015 6:14:47 PM CET Kevin Ottens wrote:
> > > I just started looking into doing the replacement and noticed that I'm
> > > also using:
> > > * Non-static data member initializers (N2756), gcc 4.7
> > > * Range-based for (N2930), gcc 4.6
> > 
> > Note that if you do that with Qt containers it's likely a bad idea. It's
> > likely to detach and copy whole containers if they are non-const. Qt
> > containers should be used with foreach always to avoid problems (and yes
> > that's a shame IMHO).
> 
> I'm aware of that and my usage of the range-based for is only in cases where
> it's not going to detach.

Still that's asking for troubles IMO. You got cases already where it actually 
calls detach() just that there's no existing copy (yet). Easy to add such a 
copy by mistake in maintenance later on. Clearly slippery and error-prone for 
everyone with no real gain.

> > > * constexpr, gcc 4.6
> > > * possibly also delegating ctors, gcc 4.7 (difficult to find)
> > > 
> > > Overall it looks to me like I cannot make this code base to work again
> > > with gcc 4.5 without spending a lot of time and possibly introducing
> > > regressions.
> > 
> > I would disagree here, it's not exactly difficult for all the cases to
> > move back to being supported by gcc 4.5. Most of the features you
> > mentioned are almost unused in your code base. I found only one constexpr
> > use, two inherited ctors, no delegated ctors. The only annoying ones could
> > be the data member initializers since you got a few in private headers and
> > the for range loop (which I think you should change anyway).

In fact I would withdraw my comment regarding range based for loops, it's 
likely one command away:
perl -npi -e 's%for\s*\((.*?)\s*:(.*?)\)%foreach (\1,\2)%' **/*.{h,cpp}

> yes, that's the annoying one which is lots of work and lots of possible
> regressions. I'm not sure whether I'm willing to do that work which I
> consider a useless exercise.
> 
> > > So how should we go on?
> > 
> > My opinion still stands: fix it. :-)
> 
> As I just said: I consider this as a useless exercise and a waste of my time
> (and of anybody else who would do that).

Note that it's a waste of time which could have been easily avoided. If the 
goal was to get something like KWayland in, the white listed constructs were 
known and documented. By choosing a more liberal approach it was necessarily 
creating a price to pay later on (the useless exercise, or bumping 
requirements for everyone reducing user base, or opening the door to 
exceptions and reducing the readability of our offer).

> If we cannot have an exception I think I'll leave KWayland in kde-workspace.

As you wish.

> > Alternatively, we could bump the compiler requirements globally for KF5
> > again. But I think it's too early for that, I'd wait for Qt 5.7 to be out
> > (since they'll move their baseline as well at that point anyway).
> 
> Well it doesn't need to be a global bump of compiler requirements.

It doesn't need to indeed. Still, exceptions are my least favorite price to 
pay in the list above (second least favorite to me is bumping requirements).

To make it clear: my opinion is that anything which reduces our user base or 
might make our offer harder to read and understand should be considered last.

> But we could consider different compiler requirements for frameworks which
> are non-portable. KWayland will never be built on Windows neither on OSX. So
> any compiler restrictions on it just shouldn't matter.

Bumping gcc requirements also has an impact on embedded platforms which tend 
to have older gcc. It's clearly one of the main nest of users for KWayland 
IMHO. I'm not sure what older gcc they tend to run with on the platforms 
supporting wayland but that's still something to consider (especially since 
wayland itself is not very demanding on the compiler as you pointed out).

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151210/c8b7a045/attachment.sig>