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