[Development] Deprecation warnings are enabled

[lars.knoll at nokia.com]

On 4/30/12 9:07 PM, "ext bradley.hughes at nokia.com"
<bradley.hughes at nokia.com> wrote:

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

I think most of them were related to qimage.h producing warnings (unless
you were using gcc 4.6 or 4.7). Enabling them is a good thing in
principle, but I agree with you that we have to be careful what we
prioritize, as we have limited time and resources.

Ideally things such as the deprecated warnings should not be enabled until
someone went through things locally and made sure the amount of warnings
doesn't drown everything else. Let's please do this the next time.

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

This one is an issue. I am partly guilty for ok'ing the change without a
discussion on the ML (as we said we should have). I think in the future,
we should have fixes for these things go into the modules *before* we push
the SIC change. And the module list has to include creator, as it's one of
our main test bed for the platform ports.
>
>> 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.

Agree that it's to late for this change. But let's learn from it. Every
source incompatible change comes at a cost (and it's usually a cost for
others who haven't done the change). Moving towards a Qt 5.0, this is
actually expensive as it disrupts other people's work.

This is the reason we should (as much as possible) stop doing source
incompatible changes now.

Cheers,
Lars


>
>> 
>> [...]
>>> 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
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development