[Geany-devel] Ideas on increasing quality of plugins

[Colomban Wendling]

Le 08/03/2011 19:58, Enrico Tröger a écrit :
> On Tue, 08 Mar 2011 11:06:16 +0100, Frank wrote:
> 
>> Am 23.02.2011 01:10, schrieb Matthew Brush:
>>> For first thing, maybe we could enforce use/passing of those tools
>>> mentioned and these before adding to release, examples:
>>> http://www.splint.org/
>>> http://valgrind.org/info/tools.html
>>> (suppression for GTK -
>>> http://people.gnome.org/~johan/gtk.suppression)
>>> http://www.gnu.org/software/indent/ (just for making coding styles
>>> more consistent between plugins) http://check.sourceforge.net/ or
>>> http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/
>>> Perhaps some or all of these could be automated.

I don't suggest (yet) to use splint, because I haven't found it useful,
it reported ways too much things (and some was false positive) to be
really usable. However, I probably don't know how to configure it (and
haven't the time to find out yet), so if somebody with experience with
it can provide some hints, maybe we can add this too.

For Valgrind however, I doubt we can do anything automatically, because
it's a runtime checker, and its output must generally be read with some
care. Writing some sort of guidelines and howto is probably the way to go.

>>
>> I like that idea. Can someone of you build up a howto on how to use it?
>> I did try valgrind in past and wished for some advice ;)
>>
>> One this is done we can think of automatic tests with some of this
>> tools.
> 
> I, and obviously, Colomban as well, though indepdent from each other :D,
> recently played[1,2] with cppcheck. A small tool for static code
> analysis which actually found a few things in the geany-plugins
> repository.
> 
> As I'm currently reworking the system to create the nightly builds, we
> could integrate such checks into the nightly builds, maybe run cppcheck
> on the sources after the builds and present the results somewhere on
> nightly.geany.org.
I think it's a good idea.

I did a few checks, and this is what I suggest:
1) run cppcheck on `make check` and abort if it detects an error;
2) enable by default (though in a portable manner) some compiler flags
such as -Werror-implicit-function-declaration [1] [2]

Maybe some other tests might be good, but I think this is a start.

I'm working on implementing this for Autotools, maybe I can take a look
at Waf too (but Enrico would love to do this :D).

Thoughts?

Cheers,
Colomban


[1] and maybe some other flags, but implicit function declaration is a
very crash-prone bug, and I can't think of (and never saw) a case where
this would break legitimate code.

[2] for example, debugger plugin currently have some implicit function
declarations -- Alexander, could you fix this?