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