On Mon, Dec 13, 2010 at 7:35 PM, Brett Nash <n...@nash.id.au> wrote: >> > >> > I don't understand why raster is so reluctant in having them. Especially >> > if we enable them only during a development cycle, and not in a release. >> >> Indeed... several projects I work with enable tons of -W when >> configured with --enable-maintainer-mode (even -Werror). I don't see a >> point against doing this. > > There are a few points. First if you are on a different arch to the > maintainers suddenly you can find yourself in warning hell. Similarly > different compiler versions have the same effect[1]. >
You are in a warning hell when everyone else do not turn on the warnings. Then there are the "warning hunt seasons", when a bunch of developers tries to turn off all the warnings. So, what's the purpose of having them? give us more work? Actually their purpose is *warning* us of things that might be wrong. This only works when they are turned on and everybody uses them. > -Werror is even worse for this (especially when you are adding a new This forces you to stop what you are doing and fix it. Maybe this would cost you a day of debugging just because you didn't pay attention to warnings. It's pretty much what happens you have several warnings: you just don't care. > feature and you know what/why a warning is but you don't want to fix it Maybe a broken workflow? > for some reason). As a person who always uses a 64bit machine + more > warnings the most, adding a -Werror is a nightmare for me. Maybe -Werror could be left out. But the more we fix and spank who introduced that bug, the more we'll ease our lives later. > > Third reason is it messes with peoples existing warning flags. For > instance I use[2][3]: > -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter > A -Wall at the end resets my other flags, which is really annoying. I'm sure vtorri would be happy to fix this in autotools. > > However the main problem is the simple philosophical one. Don't tell > people how to code. Don't tell them what editor, don't tell them what > compiler, don't tell them what architecture to use, don't tell them what > C flags. Nah... I don't see any philosophical thing here. It's just a set of pet rules we all have. Mine are: Don't cast void pointers to int. Don't use gotos when unnecessary. Warnings you add, are warnings you fix. Don't submit code without testing. I agree to most of the rules from kernel, connman and webkit, too. And some others do's and don'ts... > Having said that: People with no CFLAGS should probably be given a > default set, and suggestions of CFLAGS to use is a good idea. After having to fix *bugs* because people do not enable the warnings by default, I think it's advisable to add the --enable-maintainer-mode flag. Whenever someone tries to hack something and submit patches, he/she will need to pass this flag. I'm not the one that would like to fix the warnings *he/she* introduced (unless it's because of the architecture... then I would spank he/she first). > > [1] I was the first in my company to upgrade to gcc 4 at the time with > 'mandatory' CFLAGS, and found myself in hundreds of warnings when the > previous version was warning free. I was the first to upgrade to gcc 5. I remember I found a bug in connman because of this. And I didn't fix it, I just pointed the warning to the right person. > [2] I'll probably be adding void arithmetic to this soon. > > [3] I used to have more. I turned some off due to too many warnings > elsewhere. You've just made my point that having your own private CFLAGS does not work. Lucas De Marchi ------------------------------------------------------------------------------ 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
