[Geany-devel] Ideas on increasing quality of plugins

[Colomban Wendling]

Le 12/03/2011 01:51, Lex Trotman a écrit :
> 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 :-)
...and invalid C code should neither, but it does :(
What I mean is that it is acceptable IMO to consider some "mistakes" as
"invalid syntax".

>  In fact even errors should also
> not break the whole build, just the specific plugin.
agreed. But that's a somewhat different point I guess... maybe just tell
people to use `make -k` ^^

>> 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.
but again, what if I add

  hello guys!

in the middle of the code?
Or even more realistic (someone might even understand... :D)

  if some test { foo_bar(); }

In this case, what would you do? Blame the programmer most probably. And
you'd be right IMO :)

Cheers,
Colomban