[Geany-devel] Ideas on increasing quality of plugins

[Lex Trotman]

2011/3/13 Enrico Tröger <enrico.troeger at uvena.de>:
> On Sun, 13 Mar 2011 03:57:59 +0100, Colomban wrote:
>
> Hey,
>
> I didn't read all of the thread, so I might be missing something. But
> still.
>
>
>>> PS we are only talking about gcc flags here but I think we only
>>> supprt gcc even on Windows, right Enrico?
>
> Nope.
> We try to support ANSI C and so support any compatible compiler out
> there. Though, some years ago I tried compiling with MSVCC on Windows
> and Geany didn't compile out-of-the-box. I don't remember the exact
> problems but I also didn't care enough. MSVCC is probably not worth to
> be supported :D.

What I thought.

> But there are still other compilers like Intel's icc or suncc (is it
> called suncc? well, the compiler on Solaris).
>

What I meant was that for the quality checks we are using gcc only,
unless you also have automatic build farms for the other environments?

I thought icc was mostly gcc compatible but its a long time since I've
used it.  Dunno about the c compiler on Solaris, anyway as I
understood it Oracle had killed Opensolaris.

>
>>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 :-)

>
> 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
it overridable by the developer setting their CFLAGS to configure or
to waf.

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

Cheers
Lex

>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>