On Tue, 14 Dec 2010 10:45:16 +0200 Tom Hacohen <tom.haco...@partner.samsung.com> said:
> On Tue, 2010-12-14 at 14:35 +0900, Carsten Haitzler wrote: > > > It works for you. Do you see you are giving yourself more work by > > > fixing other's warnings? > > > > not really. patches and work can be rejected on the basis of warnings. we > > just havent done so yet. also forcing people to make things warning free > > encourages people to cast themselves into oblivion as opposed to fix the > > real issue quite often. its better to have warnings than to go hide them > > via casting (when the real solution isnt a cast) > > This is a good point, I prefer seeing the warnings myself than letting > someone silent them in a dumb way. > > > > > And if it's only an architectural issue, the warnings are pretty easy > > > to fix. At least the ones that are worth enabling by default. > > > > and by not using -Werror u dont force anyone to fix any warning. so unless > > you use -Werror your above point is fairly moot. most of e's src had > > warnings in it until a warning hunt WITHOUT any -W options (just standard > > gcc warnings). they never got fixed. reason? people just ignore them. u > > dont get them fixed unle4ss you are dedicated enough to go fix them (and > > then u are dedicated enough to add them to CFLAGS) or... you use -Werror > > and force builds to break. and then see nash's point. > > Unfortunately, this is also true, I don't get this, but I've seen many > developers that ignore warnings (i.e don't even read them). > > Raster: the problem with the current state of warnings in the system, is > that it is hard not adding warnings even when you really try. First of > all, you have no way of knowing which warnings were already there :), > but second of all, because we can't use -Werror (because it will just > break compilation until we fix all of the code), warnings are easy to > miss. > > Btw, I finally remember what we said last time we talked about it. We > said it's a good idea to add to the README/Dev guide/whatever (right > near the coding conventions?) a section that states the recommended > warning flags to be used by developers (i.e warnings of those classes > should not be added by new code). We also talked about recommended > optimization flags that belong to the README of each library. > > We should do them both someday :P on this point - i concur fully. we should have conventions/rules that developers SHOULD follow - like coding standards and naming conventions and formatting and more. a readme/guide/wiki page... no problems with it saying "you REALLY should use -W -Wall -Wextra -Wpants-off..." :) -fvisibility things too so people SEE missing symbol declarations (if your gcc supports it), not to mention probable suggested optimization flags (if you want to be able to debug efl - use -O - not -O2, and -g etc. etc.). if it were me i'd make it simple: for developers we HIGHLY suggest (with a big stick) to do: export CFLAGS="-O -g -march=native -W -Wall -Wextra -fvisibility=hidden" for packagers: export CFLAGS="-O2 -fvisibility=hidden" (only add architecture specific flags like -march=pentium etc. if you want to make a specific generation of the architecture you build for to be a minimum baseline. no one with a cpu "older" than that can use your packages then). of course the packagers may disagree with us and decide otherwise - but at least we did our best and made the suggestion. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
