[Bf-committers] introduction

[Campbell Barton]

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.

>> * 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