2011/3/13 Enrico Tröger enrico.troeger@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel