[Development] Deprecation warnings are enabled

[bradley.hughes at nokia.com]

On Apr 30, 2012, at 8:50 PM, ext Olivier Goffart wrote:

> On Monday 30 April 2012 17:57:46 bradley.hughes at nokia.com wrote:
>> On Apr 30, 2012, at 7:19 PM, ext Thiago Macieira wrote:
>>> On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hughes at nokia.com
>>> 
>>> wrote:
>>>> Seriously? What about my comment (plea) to revert the change that enabled
>>>> these warnings? As I mentioned before (and others in my team), these
>>>> warnings are hurting more than helping, and our time is much better spent
>>>> working on the desktop platform plugins than fixing warnings.
> 
> In which modules are all those warnings?

I see warnings in all Qt modules.

> For me, qtbase and few other modules compiles fine, without deprecated 
> methods.

Interesting, I will have to rebuild and see what warnings are still remaining. Last I saw, there were several hundred new warnings for qtbase alone.

> Is it in a platform plugin?
> In that case, you may want to disable deprecated warnings in that plugin only.

It is all of Qt.

> [...]
>> I've always been under the impression that the desktop platform plugins
>> won't block any release. The state they are in at release time is the state
>> they are in… we will be constantly fixing and implementing both up to and
>> and well beyond the 5.0 release. Postponing isn't feasible because it's
>> impossible to say how much time is left.
> 
> Well, it is fine to disable the warnings only for the areas that you think can 
> still use the deprecated method.

This doesn't help. The deprecated warnings from rebuilding most of Qt after changing the QPA API have been drowning out the real warnings. This may have changed recently, mind you, lots of stuff went in over the weekend. I will have to double-check on Wednesday.

>>> I've already spent almost a week getting the QRegExp const change done
>>> because it seemed like the right thing to do and required for the beta.
>>> Given the choice, I wouldn't have spent any time on it. And I have a
>>> couple more tasks assigned to me that seem to be required for the beta,
>>> but I'll happily leave them for later instead.
>> 
>> Likewise, I spent most of the day getting Qt Creator compiling again after
>> the QRegExp change (instead of working on the QPA API changes that we
>> need). Granted, not a week like you spent, but the point here is the
>> interruption.
> 
> That QRegExp change is unrelated.

Unrelated how? It was a disruption. I spent most of my day fixing Qt Creator after that change landed in qtbase.

> Personaly I think that changes break source compatibility for little gain. But 
> now it's there.

I agree. I was considering reverting the change at one point instead of having to change Qt Creator.

> Peraps we could add back the const overload, but as deprecated?

Too late now. Change is already in qtbase and Qt Creator. Time has already been spent. Nothing we can do about that now.

> 
> [...]
>> Summing up, this is what I'm afraid of: we're going to end up wasting a lot
>> of time fixing things that are in the way, not because they are important
>> right now (note that I'm not saying they are unimportant altogether, just
>> that there other things trump them).
> 
> Would it be ok for you to just enable the proper flags in the relevent 
> platform plugin .pro in order to get rid of those warnings?

No, I'm not rebuilding just the platform plugin(s), this has to do with all of qtbase (mostly). I will double check this though, since things are constantly changing everyday. The situation may have improved (but that doesn't change my position, which is that we should not be worrying about compiler warnings when the platform plugins need much more work).

--
Bradley T. Hughes
bradley.hughes at nokia.com