I'd rather not build with -Werror by default; while coding I often make quick changes that throw a few harmless warnings, then fix those things up before I commit. For example, I might temporarily declare some new variables in the middle of code, which is technically a no-no, but gcc doesn't actually care other than to print a warning.
If we somehow set up a commit script that rejected commits that add warnings to the build, that might be OK, but for normal development I think it'd be irritating. -Nicholas On Fri, Jun 4, 2010 at 3:02 AM, Campbell Barton <ideasma...@gmail.com> wrote: > On Thu, Jun 3, 2010 at 8:07 PM, Campbell Barton <ideasma...@gmail.com> wrote: >> On Thu, Jun 3, 2010 at 7:16 PM, Ian Watkins <watkin...@gmail.com> wrote: >>> On Thu, Jun 3, 2010 at 11:12 AM, Campbell Barton <ideasma...@gmail.com> >>> wrote: >>>> Hi Ian, >>>> >>>> * re: compiler warnings, I compile with CMake on linux which uses: >>>> -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align >>>> -Wdeclaration-after-statement -Wno-unknown-pragmas >>>> -Wno-char-subscripts >>>> >>>> This removes warnings which in my experience can be ignored, a few >>>> times I tried to get blender to build with less warnings (when >>>> omitting some of the flags above), but found it mostly useless. >>>> There are libraries like bullet which is really an external project so >>>> we try not to modify its source, and other cases in the game engine >>>> where there is no easy way to fix the warning. >>>> So even if you get 1000's of warnings (with only -Wall for instance), >>>> I have found its not that easy to simply go in and 'fix' many of them. >>>> >>>> I've run blenders code through cppcheck, splint, clangs error checker. >>>> We also had coverity run scans on blenders source though that was on >>>> 2.4x a while ago. >>>> >>>> nevertheless, fix warnings you find when building blender is a fine >>>> place to start. >>> >>> My experience is that if you ignore warnings, they just grow -- >>> masking problems one should probably look at. Additionally, that path >>> can lead to people caring less about warnings than they should. >>> Granted, some warnings are innocuous -- but those are typically easy >>> to fix. >>> >>> When working with a large group of people, it seems like an absolute >>> policy serves everyone the best. >>> >>> As an example, when I write code, I tend to throw -Wall -Wextra >>> -Werror and make sure it keeps building. When someone adding feature >>> to such a codebase has an issue, it is because their code is >>> (arguably) broken. >>> >>> In other words, zero warnings in (when I checked out the code) leads >>> to zero warnings out (when I commit my code back to the central >>> repository). Otherwise, how do I know if I added warnings or not? >>> >>> Just my experience. I acknowledge that this is possibly a waste of >>> time, but I'm getting several things out of it, while the rest of you >>> are getting (hopefully) fewer warnings. Seems like a good trade all >>> around. >> >> Agree that fixing warnings is important, periodically we go over and >> cleanup warnings, I'd not say that the warnings in blender are growing >> and growing. >> >> Heres a log of warnings from compiling on 64bit linux, gcc 4.4.3 >> svn r29188: http://www.pasteall.org/13554 >> ignoring bullet, there are around ~90. >> >> At one point I spent some time to try and have -Werror default but >> wasn't able to remove "implicit declaration gzopen64", Brecht also >> tried to get this working and wasn't able to. >> >> If we can resolve this I'd be OK with using -Werror, at least for a >> while and see if its acceptable with our mixed developer base. > > Correction, Brecht fixed the gzopen64 problem r21082, so with GCC at > least we could try -Werror, though with people building on different > OS's and compiler versions I'd want to avoid frequent small breakages. > >>>> * re: memory management. >>>> We have guarded alloc, which can help track leaks based on a string ID >>>> for each alloc, however it could be interesting to replace the >>>> allocator. >>>> AFAIK the only thing which makes this tricky MEM_allocN_len() which >>>> returns the length of allocated memory. this is only used in a few >>>> places so I think its use could be removed and we could swap out >>>> guarded alloc altogether, for testing/benchmarking. >>> >>> pretty much every allocator I've looked at can trivially add a similar >>> interface, with only jemalloc not being able to do it in O(1). >>> Generally, I've considered such an interface a debug extension. What >>> is this used for in the code? Offhand, I can only think of trying to >>> avoid growing a buffer with realloc, or, alternately, avoiding buffer >>> overruns. I'll grep through the code and see what's going on, I >>> guess. >>> >>>> >>>> * re: plugin system. really important to get this right for 2.5, have >>>> discussed with Brecht and Ton a little, research in this area is >>>> useful but not sure its a good first project since we need to consider >>>> how the rna api might fit in with texture, sequencer plugins and >>>> possible compositor and shader plugins too. >>>> >>>> Of your suggestions I think parallel code is a good place to start if >>>> you have experience with this in previous projects. >>>> You could take some area of blender which is self contained and >>>> optimize it without having to understand lots of different parts of >>>> blender at once. >>>> >>>> I haven't used GIT yet though I'd like to try [...] >>> >>> One of us... One of us.... >>> >>> -- >>> --Ian >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> >> -- >> - Campbell >> > > > > -- > - Campbell > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers