[Bf-committers] Making C++11 required for blender2.8 branch

Bastien Montagne montagne29 at wanadoo.fr
Tue Oct 4 11:58:11 CEST 2016


Not being much of a C++ dev, but am all for switching to C++11, that 
llvm version issue e.g. is starting to be annoying with recent Linux distro…

Will start checking on install_deps issues as soon as we have a branch 
(based on blender2.8 I assume, not master?). Also, iirc starting from 
gcc6, C++11 is default with this compiler?

Bastien

Le 04/10/2016 à 11:15, Sergey Sharybin a écrit :
> Hi,
>
> = Summary =
>
> I would like to propose to switch to C++11 in blender2.8 branch.
>
> Such a bump was already discussed in the past, but i want to give it a real
> pus forward now.
>
> = Why do we need C++11 =
>
> There are various aspects why we want C++11. Here is just couple of
> examples from own areas i meaintain.
>
> == Dependency graph ==
>
> I would like to kick old depednency graph out from 2.8 branch, so we
> wouldn't need to worry about whether particular feature is compatible with
> old depsgraph design or not. This would help laying down design and
> implementation for all the node-based and local-overrides features we need.
>
> New dependency graph uses function bindings (it's like a function pointer
> with argument values which will be passed to the function). Currently in
> release builds we depend on Boost for that. But making Boost required for
> Blender is something i'm not going to commit to. So the idea is to use
> C++11 for this.
>
> Surely, here there's an alternative to write own function bindings
> implementation (and i even have such implementation), but from benchmarks
> they are much slower than native C++11. Even Boost implementation is
> slower. This might not be an issue in other implications, but in new
> depsgraph we really have 1000s function calls per rig, so it becomes a
> bottleneck.
>
> == Cycles / Audaspace ==
>
> Cycles and Audaspace are using Boost for some code helpers like foreach
> loops and shared pointers. This features are available in C++11, so such
> transition will let us to make Blender itself free from such a heavy and
> tricky dependency as Boost (Blender release builds will still use Boost
> indirectly via OIIO/OCIO).
>
> == OpenShadingLanguage ==
>
> We are currently hitting limitation of how new OSL can be because of LLVM
> requirements. We are currently using LLVM 3.4 which is quite old (recently
> it was 3.9 released). Tricky thing is: we can't bring up newer LLVM because
> new version of it requires C++11.
>
> == Other cases ==
>
> There might be other areas in the code which will benefit and make
> development easier, i only listed things from areas i'm really familiar
> with.
>
> = What does it mean to requirements =
>
> I would really suggest sticking to a minimal allowed feature sets from
> C++11 (see below), so requirements seems to be:
>
> == Windows ==
>
> MSVC 2013 already supports quite enough of C++11, so nothing will be
> changed here
>
> == OSX ==
>
> OSX will need to be bumped to at least version 10.7, hopefully we can bring
> it up to 10.8. To my knowledge, OpenGL/viewport work will require such bump
> to 10.7 due to drivers.
>
> Details about 10.7 vs. 10.8 would better be discussed in IRC with devs who
> are motre familiar with that world than i am.
>
> But in any case, any of this bumps will require re-compiling the whole
> precompiled libraries repository. That's where we would need help of
> platform maintainers.
>
> == Linux ==
>
> Linux will require gcc-4.8, which seems to be old enough and available on
> all the platforms (even the ones recommended by vfxplatforms ;)
>
> There will also be required some work to be done to make sure all the
> dependencies are also build with C++11.
>
> Unfortunately, it's quite tricky to know in advance. Fortunately, it's only
> Blender Linux platform guys would need to solve in install_deps.sh so for
> users it'll be matter of re-running the script.
>
> = What's the plan =
>
> There are still some technical details to be discussed and figured out, but
> this we'll do much easier in IRC with platform maintainers.
>
> Here's my vision of how we can approach the migration:
>
> - Create a Git branch where we'll be (a) working on build scripts (b) do
> required tweaks to CMake and code when/if needed.
> - Create a new folder in
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/ for OSX C++11
> libraries. Not sure darwin-9 is really relevant name nowadays. Commit all
> newely compiled libraries in there.
> - Once the branch is finished and tested by active developers, merge it to
> blender2.8
>
> As simple as that :)
>
> = Next steps =
>
> Don't have much to be added here, just am open for discussions and opinion
> form active developers about such a move.
>
> Might also be missing something important here.
>
> But in any case, let's give a whirl of discussion :)
>



More information about the Bf-committers mailing list