[Bf-committers] introduction

[Campbell Barton]

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