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 :) > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
