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
On Sun, 13 Mar 2011 21:32:48 +1100, Lex wrote:
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 :-)
Why not, easy enough. However, I'm not completely sure the info in HACKING or whatever would be visible enough for every new (and current!) developer to see it, but we might start this way and see if it is OK.
Something like ./configure --enable-extra-c-warnings (or shorter if you prefer ^^)
Cheers, Colomban
On Sun, 13 Mar 2011 14:27:24 +0100, Colomban wrote:
On Sun, 13 Mar 2011 21:32:48 +1100, Lex wrote:
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 :-)
Why not, easy enough. However, I'm not completely sure the info in HACKING or whatever would be visible enough for every new (and current! ) developer to see it, but we might start this way and see if it is OK.
I agree it might get forgotten in HACKING...
Something like ./configure --enable-extra-c-warnings (or shorter if you prefer ^^)
...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Regards, Enrico
On 13.03.2011 14:35, Enrico Tröger wrote:
Something like ./configure --enable-extra-c-warnings (or shorter if you prefer ^^)
...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Why disabled by default? I don't quite understand that. Disabled by default defeats the whole purpose.
Best regards.
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
Something like ./configure --enable-extra-c-warnings (or shorter if you prefer ^^)
...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Why disabled by default? I don't quite understand that. Disabled by default defeats the whole purpose.
Portability.
Regards, Enrico
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
Something like ./configure --enable-extra-c-warnings (or shorter if you prefer ^^)
...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Why disabled by default? I don't quite understand that. Disabled by default defeats the whole purpose.
Portability.
I thought the warnings are only enabled if the compiler understands them anyway (so portability is not an issue)? That's what the initial mail about the warnings said.
Best regards.
On Sun, 13 Mar 2011 14:52:24 +0100, Thomas wrote:
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
Something like ./configure --enable-extra-c-warnings (or shorter if you prefer ^^)
...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Why disabled by default? I don't quite understand that. Disabled by default defeats the whole purpose.
Portability.
I thought the warnings are only enabled if the compiler understands them anyway (so portability is not an issue)? That's what the initial mail about the warnings said.
As I said, I didn't read all of the thread, shame on me. Still, not sure whether it can be reliably checked whether the compiler supports all the options and/or whether it's worth checking this.
Though, if you all want this, I won't hinder you. At least not for G-P.
Regards, Enrico
Le 13/03/2011 15:08, Enrico Tröger a écrit :
On Sun, 13 Mar 2011 14:52:24 +0100, Thomas wrote:
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
> Something like ./configure --enable-extra-c-warnings (or shorter > if you prefer ^^)
...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Why disabled by default? I don't quite understand that. Disabled by default defeats the whole purpose.
Agreed.
Portability.
I thought the warnings are only enabled if the compiler understands them anyway (so portability is not an issue)? That's what the initial mail about the warnings said.
Yep. I currently implemented the check by checking whether the compilation of a tiny, perfectly well-formed, C program works. Hopefully a compiler that don't understand the flag would fail (GCC does), and at least won't complain more when actually compiling the code.
As I said, I didn't read all of the thread, shame on me. Still, not sure whether it can be reliably checked whether the compiler supports all the options and/or whether it's worth checking this.
Whether it's reliable is maybe a good point, but as said above, if the compiler succeed to compile a test program with the flag on, I see no reason it wouldn't do with the real sources. And I think it's *very* unlikely a compiler understand the flag in another way than another -- at least GCC's flags are pretty explicit.
Though, if you all want this, I won't hinder you. At least not for G-P.
There would be anyway at least a way to disable them (say, --disable-extra-c-warnings). I can easily add an information message when the flag is on to tell the user she might disable them with the option if you think it's useful :)
Cheers, Colomban
On Sun, 13 Mar 2011 15:18:09 +0100, Colomban wrote:
Le 13/03/2011 15:08, Enrico Tröger a écrit :
On Sun, 13 Mar 2011 14:52:24 +0100, Thomas wrote:
On 13.03.2011 14:50, Enrico Tröger wrote:
On Sun, 13 Mar 2011 14:39:29 +0100, Thomas wrote:
On 13.03.2011 14:35, Enrico Tröger wrote:
>> Something like ./configure --enable-extra-c-warnings (or >> shorter if you prefer ^^) ...so this sounds good to me. Maybe that option could also display a hint to check HACKING for more information about flags.
Why disabled by default? I don't quite understand that. Disabled by default defeats the whole purpose.
Agreed.
Portability.
I thought the warnings are only enabled if the compiler understands them anyway (so portability is not an issue)? That's what the initial mail about the warnings said.
Yep. I currently implemented the check by checking whether the compilation of a tiny, perfectly well-formed, C program works. Hopefully a compiler that don't understand the flag would fail (GCC does), and at least won't complain more when actually compiling the code.
As I said, I didn't read all of the thread, shame on me. Still, not sure whether it can be reliably checked whether the compiler supports all the options and/or whether it's worth checking this.
Whether it's reliable is maybe a good point, but as said above, if the compiler succeed to compile a test program with the flag on, I see no reason it wouldn't do with the real sources. And I think it's *very* unlikely a compiler understand the flag in another way than another -- at least GCC's flags are pretty explicit.
Though, if you all want this, I won't hinder you. At least not for G-P.
There would be anyway at least a way to disable them (say, --disable-extra-c-warnings). I can easily add an information message when the flag is on to tell the user she might disable them with the option if you think it's useful :)
I do. Sounds good so far, let's hope it won't break anything.
Regards, Enrico