[Geany-devel] Ideas on increasing quality of plugins

[Enrico Tröger]

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 :-)
>>
>> Ok.
>> 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
>>>> convenience.
>>>
>>>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.


Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20110313/6eb5b9ae/attachment.pgp>