[Bf-committers] FAQs on blender development and GSoC

[Tom M]

Hi all, I've recieved a bunch of questions recently from potential
GSoC applicants and also those interested in developing for Blender
outside of GSoC.  So thought It might be of value to others looking to
do Blender development

Here ya go,

LetterRip

Q: What will most help my odds of acceptance?

A: There are a number of things you can do to help your odds

1) A quality proposal - a well thought out proposal that shows you
understand what you want to do and have reasonable expectations about
what can be accomplished in the time you will have available
2) Make a useful patch against Blender - this show that you can
successfully read, edit, and compile our code.
3) Discuss your application with us and get some feedback you can chat
with us on IRC and post a link to your proposal to our mailing list,
and of course we will give feedback in the GSoC interface also.

Q: Is there some place that tells me the process of compiling Blender?

A: See the following documentation -
http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender

Q: Where can I learn more about Blenders code base?

A: There is quite a bit of good documentation here -
http://wiki.blender.org/index.php/Dev:2.5/Source

Q: The Blender code base is huge! Where do I start?

A: The editor directory is usually a good place - it is where most of
the operators live. Have a look at the header files and structs
related to what you are interested in working on. The headers usually
have the best overview of what a function does. (To find the struct a
simple grep or other search for struct FooStructIWantToLookAt will
find it for ya.) You can also start with writing python scripts, the
API for our python tools is similar in many ways to our C API. You can
often find out where some C code lives by seeing the python tool tips
by hovering over a button and seeing what the operator name is. Also
if you add a console window you can see what is output to it when you
do an action. Then just search the code. Also putting a break on a
function in a debugger and doing a back trace can help you find the
path code took to get to your function of interest.