[Bf-committers] introduction

[Ian Watkins]

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.

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