[Qgis-developer] Q/A Compiler Warnings

[Matthias Kuhn]

On 06/16/2015 02:03 PM, Sandro Santilli wrote:
> On Tue, Jun 16, 2015 at 01:54:34PM +0200, Matthias Kuhn wrote:
>
>> The plan is to let travis test for warnings and if there are warnings
>> mark the build red. With this in place, an author of a commit will be
>> required to spend some thoughts on a warning and take care of it before
>> merging into master. As an example, if you deprecate a method, you will
>> have to check where it is used, where it can be updated to its successor
>> and where it's required to use the deprecated method and appropriately
>> put macros there.
> I'm happy to fight the warnings, but in this final plan I envision the risk
> to break backward compatibility. What I mean is that if someone deprecates
> a method, he should still make sure the deprecated method still works.
> Having some internal code path using the deprecated method (maybe only in
> tests) would serve that purpose. But will raise the warnings.
In an ideal world, all internal code would be ported to the new API and
some tests guarantee that the legacy API keeps working as expected.
Sometimes it may also be ok to leave internal code use the deprecated
API. It just has to happen consciously.
>
> Incidentally, you hadn't mentioned how your "hushing" macro work, as they
> may be an answer to this concern of mine.
See here e.g.
https://github.com/qgis/QGIS/blob/master/tests/src/core/testqgsmaptopixel.cpp#L34-L36