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 -- Tom. ------------------------------------------------------------------------------ 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
