On Thu, 2010-08-19 at 06:59 +1000, Carsten Haitzler wrote: > as for forcing -W's into builds. no. this is compiler dependent AND it's the > task of CFLAGS. you can make this happen for you NOW. > > export CFLAGS="-W -Wall -Wextra -Werror" Nope doesn't work, as can be seen by the Makefile generated by autotools: CFLAGS = -g -O0 -D_GNU_SOURCE (-g and -O0 are mine) i.e it sets the CFLAGS and does not use the old value. (also confirmed by actually trying to build like that).
The only way I know of (and I'm really no expert) is passing the flags you want to autotools which is not much of a hassle as well so the CFLAGS not working is not the issue here anyway. > etc. done. nothing to be changed anywhere in any svn in any source tree. by > putting it on there you force error output for those that simply dont want it > OR don't care and wont read it anyway, or it simply confuses them. If people writing code to efl (as Vincent Torri said we can do it only for devs) get confused/don't care about warnings we have a major problem here. As I said, Warnings are great for finding bugs and once you also use -Wno-unused-parameter you also get rid of the more annoying ones :P > we have > enough gentoo users who are unable to read as it is. (sorry - have to say > that, > but it's true - there are enough who simply paste compiler output just so we > can become reading services. SIMPLE errors like "blah.h not found" and having > to tell them "well blah.h is not found. maybe you need blah?"). As I said, only for devs and we can even make a --disable-warnings flag that forces disabling warnings even in dev builds. > haven't you > seen enough pasts of "but when e starts, it logs errors about this hash being > null,. that must be the bug why it segv's" without ever using gdb. because > something prints out "warning" to people who have no idea what the waninng > actually means, it sends them off on a vector wasting their and our time. I have seen many of this sort, but I don't think that the ignorant few should steer our development procedures. > > other than that, -W's are the job of your CFLAGS and you can, if you want them > and to fix wanrings, set it up in your bashrc or have an alias that changes > your cflags to add them in etc. etc. eg: > > alias cflagwarn='export CFLAGS=$CFLAGS" -W -Wall -Wextra -Werror"' I don't want to fix warnings, I want people to fix their warnings. Using this method I can (and for example devilhorns does) fix people's warnings but it's not mine or devilhorn's or anyone's job. Mainly because we are not slaves that are used to fix people's warnings but also because warnings indicate code issues and us fixing them without fully understanding the code in question will just mean we'll probably break more than we fix. > before doing efl compiles. setting warning flags simply does not belong in the > makefiles, configure scripts etc. of a project. if you say "well lets make it > a --enable-warnings" then just SET YOUR CFLAGS instead! there is no point in > involving configure. No --enable-warnings won't have the same effect, I want to force people writing warning-less code and making warnings off by default will not achieve that. > > this does not mean i hate the warnings and discourage them in general - it > just > is not the place for them to be set on by default in configure scripts. Warnings are awesome, they really help finding coding mistakes and improve the quality of code. -- Tom. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
