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
pgpULsz8lSUPQ.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel