[Bf-committers] C++11 Audaspace

Sergey Sharybin sergey.vfx at gmail.com
Wed Apr 15 17:09:25 CEST 2015


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.


On Wed, Apr 15, 2015 at 3:38 PM, Jörg Müller <nexyon at gmail.com> wrote:

> Hi,
>
> so it is mostly a problem for Linux, not for Windows and Mac?
>
> Regarding compilation we could build only audaspace in C++11 mode?
>
> We can also do 1 and 2, so you can then choose between 3 options
> (including old audaspace for Linux builds).
>
> I meant 2.78, not 2.48, sorry.
>
> Regards
>
> On 2015-04-15, 00:30 Sergey Sharybin wrote:
> > Hi,
> >
> > That'd be a good idea to cover benefits which can be measured by artists
> ;)
> > Are there gonna to be loads of bugfixes, new features?
> >
> > As for C++11 in general, there are several technical issues:
> >
> > - It'll piss off majority of the render farms and some studios which are
> > using Blender and which for one or another reason are using operation
> > systems like CentOS or even RHEL. We can't just ignore this fact when
> > making decision in here.
> >
> > - While majority of Blender is happy about C++11 it is still not fully
> > ready for this. For example you need latest versions of OIIO and OSL
> (which
> > are not released yet) in order to make compilation process smooth and
> > successful.
> >
> > - If you're using any C++11 subset which requires gcc-4.8 then you'll
> 100%
> > need to hold on such a change for until official Linux release
> environment
> > gets upgraded. Currently it uses gcc-4.7 and updating to newer gcc is
> real
> > PITA because it implies using newer libc, which also implies bumping
> > minimal system requirement for the official Linux builds.
> >
> > For packaging i wouldn't rely on it because not everyone is living on the
> > bleeding edge with RR Linux distros. To be honest, being accepted for
> Arch
> > does not convince me, i'll be more convinced once the library is accepted
> > into Debian (if it's be accepted into CentOS/RHEL i'll also be pretty
> much
> > convinced :). For until then sticking to an in-source lib is better idea.
> >
> > --------
> >
> > Answering your request for comments:
> >
> > - If the library is more or less same size think 2) is better (less
> > intrusive at least) way to go. Additionally to that, you can also have
> > WITH_SYSTEM_AUDASPACE (same as we do with some other libraries).
> > - Not totally clear what exact version you meant instead 2.48, but there
> > are technical issues which needs to be addressed first.
> >
> >
> > On Wed, Apr 15, 2015 at 2:39 AM, Jörg Müller <nexyon at gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> the C++11 version of audaspace (Blender's audio library) [1] is ready to
> >> be used in Blender. The library is in a ready to release state and I
> >> have successfully built and used it on Windows, Mac and Linux. Idealy I
> >> would like to have it in the release of Blender 2.76. To integrate it
> >> back into the Blender source tree there are two possible solutions:
> >>
> >> 1. we have it as an dependency like most other libraries. This means
> >> that the prebuilt library is in the lib svn folder [2] for Windows and
> >> Mac. Linux developers would need to have it installed. There is a
> >> package [3] for Arch linux already for example, creating packages for
> >> other distributions shouldn't be too difficult.
> >>
> >> 2. we build it as part of our build system and put the source code in
> >> the extern folder like other libraries such as bullet or libmv. The
> >> current version is in the intern folder.
> >>
> >> I have a patch that implements solution 1 for Linux so far and it keeps
> >> the old version in intern and adds an option to cmake with which you can
> >> switch between old and new audaspace.
> >>
> >> To build the library a compiler with full C++11 compatibility is needed,
> >> that means clang starting with version 3.3 (lower might be enough for
> >> audaspace), gcc 4.8 and msvc 2013. Mingw doesn't work as they don't
> >> support std::thread yet for example.
> >>
> >> I am now asking for comments and suggestions and especially whether the
> >> first or second option are prefered. The plan would be to implement and
> >> test this then until 2.48 is released and merge it to master as soon as
> >> master is open after the 2.48 release.
> >>
> >> Regards,
> >> Jörg
> >>
> >> [1] https://github.com/neXyon/audaspace
> >> [2] https://svn.blender.org/svnroot/bf-blender/trunk/lib/
> >> [3] https://aur.archlinux.org/packages/audaspace-git/
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin


More information about the Bf-committers mailing list