On Thu, 19 Aug 2010 11:09:44 +0300 Tom Hacohen <tom.haco...@partner.samsung.com> said:
> 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. 5:38PM ~/C/evas > echo $CFLAGS -W -Wall -Wno-unused-parameter -pipe -fvisibility=hidden 5:39PM ~/C/evas > grep CFLAGS Makefile CFLAGS = -W -Wall -Wno-unused-parameter -pipe -fvisibility=hidden -D_GNU_SOURCE ooh look at that. works for me. has always worked for me - ever since. never has been a need to screw with any configure file. there never should have been. never should be. IF people tart ADDING in stuff to screw with your cflags to add warnings forcibly then you will never have a choice of what warnings to use and how as configure will battle with your flags. > > 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 not people writing code - "gentoo users complaining about shit not compiling". they have enough problems being able to read the output of gcc as-is. people who write code can set their CFLAGS as part of their env "hey - i'm a developer. i actually set CFLAGS". if you are a dev and dont set CFLAGS as readily as you set PATH or other env vars.. then you need to re-think being a dev :) > > 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. as above. CFLAGS should already work. there should be no need for any configure script hackery anywhere. > > 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. i'd agree with that. so... why don't you just set CFLAGS then :) > > 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. see above. i made my point on that. :) > > 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. that entirely depends. i've been doing this for a long time. i used to think like you do. long ago. but then i spent enough time just sighing at gcc's stupid warnings and wanting to just focus on getting shit done and not cleaning up every tiny little thing as as i go and not having to find the important warnings from the host of unimportant ones in output. time taught me that there is a time and place to turn on such warnings and a time and place not to and just get some code done - warnings or not. when you get to a warning fixing binge.. you to -Werror... and you turn OFF make -j - as then you at least get the error as the output before your compile barfs. you have to do BOTH otherwise u get parallel makes competing and often having your actual errored. warning quite a long way up. experience has taught me that the job of -W* stuff is the job of the developer - not configure. > > > > 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. > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
