[Bf-committers] Making C++11 required for blender2.8 branch
sergey.vfx at gmail.com
Tue Oct 4 11:15:57 CEST 2016
= 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
== 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
= 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
== 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
== 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
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 :)
With best regards, Sergey Sharybin
More information about the Bf-committers