Re: Moving KWayland to frameworks

[Martin Graesslin]

On Thursday, December 10, 2015 1:07:42 PM CET Boudhayan Gupta wrote:
> On 10 December 2015 at 12:32, Martin Graesslin  wrote:
> > 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.
> 
> In my opinion this discussion is an useless exercise, because:
> > Well it doesn't need to be a global bump of compiler requirements. 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.
> 
> Exactly. Anything that's Wayland related is supposed to be on the
> bleeding edge right now. Setting compiler restrictions on this
> particular framework will serve only to (apologies for my language,
> but there really is not a more apt term for this) cockblock KWayland
> development. Developing new technologies from scratch is hard; being
> unable to use easier constructs for solving problems not only makes
> your job harder but frustrates you more (it's there, why can't I use
> this?)
> 
> I may be wrong, but I'm guessing Wayland came quite a while after
> gcc-4.5 did, and that they use features that require gcc>4.5.

I rather doubt that this is actually the case. Wayland is a c-library and we 
need to explicitly set in KWayland:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu90")

in order to compile generated Wayland protocols.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Kevin Ottens]

On Thursday 10 December 2015 12:43:29 Martin Graesslin wrote:
> On Thursday, December 10, 2015 12:24:06 PM CET Kevin Ottens wrote:
> > > 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.
> 
> KWayland originated from KWin which already used full C++11 support at that
> time. The aim was to use it in other parts of workspace at that time. Moving
> into frameworks was not a direct aim at that time. It's something which
> showed up as possibly useful only later on.

Right, hence my "if" earlier. I guess we'll see more cases like that in the 
future. We're in a similar situation in Zanshin, I proactively reduce the 
amount of C++11 I use there for anything which looks reusable in KF5.

> > 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).
>
> In my opinion it's not realistic to restrict the gcc compiler requirement
> anyway. We don't have CI coverage for it, so we never know whether it
> actually would compile. My linux distribution doesn't provide gcc < 4.8
> anymore, I wouldn't know how to ensure that the code actually works. This
> makes it in my opinion unrealistic that I try to restrict the compiler
> requirement again.

By the same argument we would not even try to support VS2012. We have the same 
issue there. I agree with the fact that the CI support is not up to the task 
for now, I'm not sure that's a reason to ignore the issue preventing the CI to 
ever catch up.

> Anyway, I don't see that I have time to rewind the C++11 usage. As we cannot
> increase the compiler requirement we probably have to keep KWayland in kde/
> workspace and retry once frameworks increases the requirements. Fine with
> me. It makes our lifes a little bit harder, especially for
> plasma-frameworks, but we will be able to manage that.

Fair enough. I wish the compilers would propagate faster though. :-)

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

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



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Martin Graesslin]

On Thursday, November 5, 2015 11:10:49 AM CET Kevin Ottens wrote:
> Hello,
> 
> On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> > There are two things which make the move to frameworks difficult and I
> > don't see a solution to it at the moment:
> > 
> > 1. We require C++11 without exceptions: reason, it's designed for Linux
> > and
> > it didn't come to my mind to restrict us on the compiler due to lack of
> > support in Visual Studio.
> > 
> > 2. We use Qt 5.4.
> > 
> > For item 1 I only see the possibility of adding an exception [1].
> 
> I personally don't like exceptions, it gets complex fast.
> 
> Now are you sure it is really problematic? To me it looks like you're using
> almost exclusively features from the white list. It is probably just a
> matter of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your
> case.

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
* 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.

So how should we go on?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Kevin Ottens]

Hello,

On Wednesday 09 December 2015 10:07:50 Martin Graesslin wrote:
> On Thursday, November 5, 2015 11:10:49 AM CET Kevin Ottens wrote:
> > Hello,
> > 
> > On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> > > There are two things which make the move to frameworks difficult and I
> > > don't see a solution to it at the moment:
> > > 
> > > 1. We require C++11 without exceptions: reason, it's designed for Linux
> > > and
> > > it didn't come to my mind to restrict us on the compiler due to lack of
> > > support in Visual Studio.
> > > 
> > > 2. We use Qt 5.4.
> > > 
> > > For item 1 I only see the possibility of adding an exception [1].
> > 
> > I personally don't like exceptions, it gets complex fast.
> > 
> > Now are you sure it is really problematic? To me it looks like you're
> > using almost exclusively features from the white list. It is probably just
> > a matter of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your
> > case.
> 
> 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).

> * 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).

> So how should we go on?

My opinion still stands: fix it. :-)

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).

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

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



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Martin Graesslin]

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.

> 
> > * 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).

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). If we cannot have an exception I 
think I'll leave KWayland in kde-workspace.

> 
> 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. 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.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Boudhayan Gupta]

On 10 December 2015 at 12:32, Martin Graesslin  wrote:
> 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.

In my opinion this discussion is an useless exercise, because:

> Well it doesn't need to be a global bump of compiler requirements. 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.

Exactly. Anything that's Wayland related is supposed to be on the
bleeding edge right now. Setting compiler restrictions on this
particular framework will serve only to (apologies for my language,
but there really is not a more apt term for this) cockblock KWayland
development. Developing new technologies from scratch is hard; being
unable to use easier constructs for solving problems not only makes
your job harder but frustrates you more (it's there, why can't I use
this?)

I may be wrong, but I'm guessing Wayland came quite a while after
gcc-4.5 did, and that they use features that require gcc>4.5.

IMO non-portable frameworks should not be subject to the global
compiler requirements at all, but use more platform-appropriate
compiler requirements.

-- Boudhayan
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Martin Graesslin]

On Thursday, November 5, 2015 10:50:06 AM CET Martin Graesslin wrote:
> 2. We use Qt 5.4.

Given David's suggestion on having the last three released Qt releases 
supported, this issue will resolve itself once Qt 5.6 is released. Given that 
this is on the horizon I will delay the move of KWayland to frameworks till Qt 
5.6 is released and Qt 5.4 the required frameworks version.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Moving KWayland to frameworks

[Martin Graesslin]

Hi,

after the Plasma 5.5 release I would like to move KWayland to frameworks. The 
main reason is that it is oddly placed in plasma-workspace as it's also a 
library useful for applications (example kde-connect uses it already).

KWayland is designed to be a tier1/integration framework. The current 
dependencies are:
* QtGui 
* Wayland Client (1.7)
* Wayland Server (1.7)
* EGL

License is  LGPL version 2.1, or version 3 or later versions approved by the 
membership of KDE e.V.

There are two things which make the move to frameworks difficult and I don't 
see a solution to it at the moment:

1. We require C++11 without exceptions: reason, it's designed for Linux and it 
didn't come to my mind to restrict us on the compiler due to lack of support 
in Visual Studio.

2. We use Qt 5.4.

For item 1 I only see the possibility of adding an exception [1]. For 2 it 
might be possible to get it down to 5.3 again. The biggest usage of Qt 5.4 
code is the new QSignalSpy syntax in autotests. I don't want to remove that, 
but it's of course possible to make autotests to only build with Qt 5.4. Of 
course I would also accept an exception ;-)

Given the release schedule I would target either the January or February 
frameworks release for inclusion.

Opinions?

Best Regards
Martin Gräßlin


[1] It might make sense to formalize the exception that integration frameworks 
which are not buildable on some platforms are not bound to restrictions of 
that framework.

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KWayland to frameworks

[Kevin Ottens]

Hello,

On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> There are two things which make the move to frameworks difficult and I don't
> see a solution to it at the moment:
> 
> 1. We require C++11 without exceptions: reason, it's designed for Linux and
> it didn't come to my mind to restrict us on the compiler due to lack of
> support in Visual Studio.
> 
> 2. We use Qt 5.4.
> 
> For item 1 I only see the possibility of adding an exception [1].

I personally don't like exceptions, it gets complex fast.

Now are you sure it is really problematic? To me it looks like you're using 
almost exclusively features from the white list. It is probably just a matter 
of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your case.

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

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



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel