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

[Dalai Felinto]

Hi Sergey,

> I would really suggest sticking to a minimal allowed feature sets from
C++11 (see below)

I think you forgot the part explaining which subset of C++11 you would
suggest to be allowed.

Also, can that said subset be forced via build options (or rather, can we
make sure using something other than the agreed on will raise errors)?

Cheers,
Dalai

On Oct 4, 2016 06:58, "Bastien Montagne" <montagne29 at wanadoo.fr> wrote:

> 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
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>