[Geany-devel] Ideas on increasing quality of plugins
lists.ban at xxxxx
Sat Mar 12 00:44:00 UTC 2011
Le 12/03/2011 01:32, Lex Trotman a écrit :
> On 12 March 2011 11:23, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>> Le 12/03/2011 01:18, Lex Trotman a écrit :
>>>>> Maybe some other tests might be good, but I think this is a start.
>>>> I'd like to commit this to the Autotools build system:
>>>> 1) run cppcheck on `make check`;
>>>> 2) enable by default, if compiler understands them, the following
>>>> warnings (discussed in other mails of this thread):
>>>> * -Werror=implicit-function-declaration
>>>> * -Werror=pointer-arith
>>>> * -Wundef
>>>> * -Wshadow
>>>> * -Wwrite-strings
>>> Good start.
>> Feel free to suggest more :)
>>>> There are currently 2 problems that would prevents the tests to pass:
>>>> 1) The debugger plugin don't compile with
>>>> -Werror=implicit-function-declaration (this should be fixed --
>>>> Alexander, could you fix them please?);
>>>> 2) cppcheck reports an error on geanylatex plugin; but I know Frank
>>>> already fixed this and so has probably only to import the fix in the
>>>> geany-plugins copy.
>>>> 1 is really problematic since it require one to disable the debugger
>>>> plugin to be able to compiler the others,
>>> Why do we have to disable the dubugger, sure it gives warnings, but
>>> for nightly builds and SVN builds thats ok, the disabling only comes
>>> at release time.
>> Since I set -W*error=*implicit-function-declaration, the implicit
>> function declaration warnings are treated as errors and then aborts the
>> build (unless one uses make -k of course).
>> We could downgrade this to a warning, but I think this is a problem
>> important enough to trigger an error.
> The general consensus seemed to be to not disable plugins from the
> nightly builds or SVN just because they fail some tests, so these will
> have to all be warnings.
It's a bit more complicated IMO: if these warnings are on by default in
everyone's build, a code failing with them would just be as invalid as
an invalid C code (e.g. breaks everyone's build, and isn't acceptable at
The problem here is that there is currently a plugin that can't be
compiled with them, so enabling them would mean disabling the plugin
that used to build.
Maybe the solution is to wait for Alexander to fix these problems, and
then enable the "errors".
> There still seems to be some discussion on how to handle plugins that
> don't compile cleanly, or have documentation at release time.
More information about the Devel