[Geany-devel] Ideas on increasing quality of plugins

[Lex Trotman]

On 12 March 2011 11:44, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> 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
> all).

Well on the development code base warnings should not break the build,
if they do thats another problem :-)  In fact even errors should also
not break the whole build, just the specific plugin.

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

But the next patch commit on any plugin could fail one of the checks,
so then the whole dev build fails again, thats no good, its got to
still build with warnings, its a development build after all.

Cheers
Lex

> Cheers,
> Colomban
>
>>
>> There still seems to be some discussion on how to handle plugins that
>> don't compile cleanly, or have documentation at release time.
>>
>> Cheers
>> Lex
>>
>>
>>>
>>> Cheers,
>>> Colomban
>>>
>
>