[Bf-committers] introduction

Nicholas Bishop nicholasbishop at gmail.com
Fri Jun 4 15:52:51 CEST 2010

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.


On Fri, Jun 4, 2010 at 3:02 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Thu, Jun 3, 2010 at 8:07 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> On Thu, Jun 3, 2010 at 7:16 PM, Ian Watkins <watkinsig at gmail.com> wrote:
>>> On Thu, Jun 3, 2010 at 11:12 AM, Campbell Barton <ideasman42 at 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 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> --
>> - Campbell
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list