[Qgis-developer] Q/A Compiler Warnings

Nyall Dawson nyall.dawson at gmail.com
Mon Jun 22 05:03:14 PDT 2015


On 16 June 2015 at 21:54, Matthias Kuhn <matthias at opengis.ch> wrote:
> In the quest for an always closer-to-perfection state of code, some
> goblins tried to get the warning count (on gcc and clang) yesterday as
> close to zero as possible. This was done in order to allow you (as a
> developer) to see if your code changes cause warnings without scrolling
> through heaps of meaningless warnings.

Thanks goblins! Your work in much appreciated :)


>
> At the moment most of the warnings left originate from the geometry
> refactoring and point to empty methods which have not yet been
> implemented. These warnings point to real problems and should be fixed
> as soon as possible, in order to have some time left before release to
> be able to test the fixes before the release. @Marco, what is your
> schedule concerning these?

I've just pushed some fixes to master which reimplement these stubbed
methods and comment out some of the unimplemented new methods. 2.10
release was approaching too close for comfort to leave these in!
@Marco Please let me know if I've made any errors doing this...


> 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.
> IMO this workflow should be preferred to merging code which produces
> warnings of which the community (i.e. "somebody out there") will have to
> take care of.

Big +1 from me to this!

Nyall


More information about the Qgis-developer mailing list