[Geany-devel] Ideas on increasing quality of plugins
enrico.troeger at xxxxx
Sun Mar 13 10:37:05 UTC 2011
On Sun, 13 Mar 2011 21:32:48 +1100, Lex wrote:
>>>>>Actually I check whether the compiler understand each flag, so it
>>>>>would be easy to support any compiler. I only talk about GCC
>>>>>warnings because I only know GCC's flags, but if somebody knows
>>>>>some other, we might add them.
>>>> Do you want to integrate these flags into the build system? I don't
>>>> think this is a good idea. Such flags should be set outside of the
>>>> build system by the developer/user, not automatically.
>>>> This is why they are mentioned in HACKING.
>>>I had understood that the idea for including them in the build system
>>>is so that plugin developers can all test with the set of options
>>>which are to be used for the quality check and everyone can be sure
>>>to have used the same set. And the nightly builds use the same. I
>>>think if we want to encourage the use of suitable quality controls
>>>we should make it easy to do the right thing :-)
>> In my previous mail I mainly referenced to Geany, forgot to
>> explicitly mention this.
>Oh, Ok I was only talking about the plugins since its what Frank
>started the thread on, I believe Geany itself is checked with lots of
Yeah, sorry for the confusion. My bad.
>> The plugins aren't that portable anyway :(.
>>>> We could maybe add a little wrapper script into the scripts/
>>>> directory which sets a bunch of compiler options we like, for
>>>Having scripts like these is non-standard so it would have to be
>>>*well* documented. I still personally prefer in the build so long as
>> Ok. But if it's in the build system, it should be optionally and
>> disabled by default, at least.
>Ok by me. (So long as how to enable it is obvious somewhere, unlike
>most other configure options, I'm still not sure how to generate
>plugins for non-standard prefixes using autofools :-)
Me neither. I use Waf and ./waf --help exists :D.
>>>> Below is a list of flags I currently use for Geany though I didn't
>>>> touch this list for months actually.
>>>> export CFLAGS="-Wall -O2 -g -pipe -march=athlon64 \
>>>> -D_FORTIFY_SOURCE=2 \
>>>> -DGEANY_DEBUG \
>>>> -DGEANY_DISABLE_DEPRECATED \
>>>> -fno-common \
>>>> -funit-at-a-time \
>>>> -Waggregate-return \
>>>> -Wdeclaration-after-statement \
>>>> -Wdisabled-optimization \
>>>> -Wfloat-equal \
>>>> -Wformat=2 \
>>>> -Wformat-nonliteral \
>>>> -Wformat-security \
>>>> -Winit-self \
>>>> -Winline \
>>>> -Wmissing-field-initializers \
>>>> -Wmissing-format-attribute \
>>>> -Wmissing-include-dirs \
>>>> -Wmissing-noreturn \
>>>> -Wmissing-prototypes \
>>>> -Wnested-externs \
>>>> -Wpointer-arith \
>>>> -Wredundant-decls \
>>>> -Wshadow \
>>>> -Wsign-compare \
>>>I think most of your warnings have been captured by Colomban, The
>>>-fno-common is an interesting portability check but probably not one
>>>to impose on plugins that will be separate libraries anyway.
>>>The rest are specific to what you want to do (eg march=athlon64) so
>>>are not really relevant unless I have missed something.
>> Yup. The list was not meant as 'this is how it should be', just to
>> show I also use a set of custom flags I prefer. And that I didn't
>> maintain the list for a long time, just use it :D.
>Must be good then :-)
If you say so :D.
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Devel