[Soc-2018-dev] Several questions about working on the code

Joshua Leung aligorith at gmail.com
Sat May 19 09:51:43 CEST 2018


Hi Yiming,

1) That depends a lot on where the code will go, though it is preferable
that all new code conforms to these guidelines.
-If it goes in source/blender and integrates with the rest of our C code
(blenkernel, draw engines, editors, etc) you'll need to make it match our
code style.
- If it is going into intern or extern libs folders, we are a bit less
strict about this, mainly since we bundle a few externally maintained
projects (eg audaspace, bullet, gl...) that need to be updated to upstream
releases in future.

2) For all non core modules (eg freestyle, bullet/rigid body, cycles,
ffmpeg, and some physics sims/modifiers, we typically have cmake options to
turn those modules off when compiling so people can have faster/lighter
builds.

If these are just configuration options for testing different code paths,
we can look into this later.



Hope that helps,
Joshua


On Sat, May 19, 2018, 3:02 AM n w <xp8110 at live.com> wrote:

> Hi devs,
>
> I have two quick questions on working on the code:
> 1) I've read the code style guidelines on blenderwiki, since
> I'll be porting code from exiting project, do I have to chage all functions
> and struct naming to match the guideline?
> 2) Is it required to add cmake options for building seperate module? If it
> is so could anyone share a way that achieves this? I'm not quite familiar
> with cmake files but making #ifdef brackets for source code works just fine
> on me.
>
> Thanks,
> YimingWu
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180519/84bf3670/attachment.html>


More information about the Soc-2018-dev mailing list