[Bf-committers] C++11 Audaspace

[Jörg Müller]

Hi,

I've talked to Campbell about this on IRC as well, he suggests that we 
do both, have the library in extern and allow a system installed with a 
corresponding cmake option.

I've tried to build audaspace C++11 with older versions of gcc, it works 
fine with gcc 4.7.4 and it needs minor changes to work with gcc 4.6.2, 
so I think we would be fine to use it.

The benefit is at the moment a better Python API and a more stable 
library. In the long run there will be more benefits as new features 
will be added only to the new audaspace. One of the planned features is 
to implement native audio backends for each platform, so that we have 
direct support of Core Audio (Windows, Mac, different libraries but same 
name...), ALSA and pulseaudio. This should also result in closing some 
bugs in the tracker that are caused by OpenAL soft for example.

So my plan is to integrate the new library with blender and merge this 
to master after the 2.78 release if we approve it in bcon1. The point is 
to have it in master and test it on all platforms. Keeping the old 
version allows to use that for release still, we can delete it as soon 
as we decide to release with the new version.

Any further comments on this?

Regards,
Jörg

On 2015-04-15, 17:09 Sergey Sharybin wrote:
> I'm not sure why you cncluded it's mainly Linux issue. You'll need to
> upgrade OIIO/OSL on all platforms i.e. You might avoid doing that if
> audaspace is only communicated via C-API (which i'm not sure about). Plus
> if requirenment is indeed gcc-4.8, then we can't limit C++11 to audaspace,
> sine it'll fail to compile anyway.
>
> On Windows msvc2013 silently provides you some subset of of C++11. On OSX
> official builds are done with clang-3.5 with openmp patch, i'm not sure
> what regular users are using there for compilation. For a long time it was
> gcc on buildbot machine.
>
> About using old audspace for linux -- all the releases must use same
> library versions. You can't updade one library for one platform and keep
> old library for another.
>
> Again, actual question which is about whether we really want to cause such
> a build environment requiruirenment bump. And in order to make decisions
> about that it is important to know what users will gain from this (which is
> still unclear). We don't break anything just because it makes code nicer.
>