[Bf-committers] Changes to Windows Compiler Support.

blendergit blendergit at gmail.com
Sat Jan 27 10:32:30 CET 2018


+1 on all points.

Antonio

De: Aaron Carlisle
Enviado: sábado, 27 de enero de 2018 1:39
Para: bf-blender developers
Asunto: Re: [Bf-committers] Changes to Windows Compiler Support.

+1 From me too.

Re fully dropping 32bit

I think this is an acceptable change the biggest issue we may have here is
schools and other small teachings institutes running older hardware.
However, like we said they can stick to 2.7x.
Any serious artist (one who will want the newest features) will probably
be running 64-bit and won't affect artists.

On Fri, Jan 26, 2018 at 3:38 PM, Danrae Pray <blink.ornitier at gmail.com>
wrote:

> Big +1 from me.  Especially the notes about dropping ancient hardware
> support...
>
> Thanks for the great work on Windows stuff Ray!
>
> On Jan 26, 2018 12:54 PM, "Mike Erwin" <significant.bit at gmail.com> wrote:
>
> > +1 on all points.
> >
> > Unifying around MSVC 2017 would clean up our build instructions & benefit
> > from MS's latest bug fixes.
> >
> > MacOS has been 64-bit only since 10.7 (Lion) so it won't affect any users
> > there.
> >
> > While I appreciate vintage computers, and have lots of 32-bit systems
> > myself, I don't expect to run the latest software on them.
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Fri, Jan 26, 2018 at 12:51 PM, Ray Molenkamp <ray at lazydodo.com>
> wrote:
> >
> > > All,
> > >
> > > With 2.8 coming up I'd like to make some changes to the supported
> > > compilers for Blender. However since these are rather large changes
> > > I'd like to give everyone an opportunity to express any concerns.
> > >
> > > Issues:
> > >
> > > 1) Currently we support msvc 2013(vc12)/2015(vc14)/2017(vc14)
> > > for building, however we ship all our releases with msvc2013(vc12).
> This
> > > has
> > > lead to some interesting issues with python, since any binary addons
> the
> > > user
> > > might install with pip (or just manually copy in) will be using the
> vc14
> > > crt.
> > > It's rare to run into issues, but when it does it's an instant process
> > > termination
> > > (the crt does not deal meeting it's future/past self very well)
> > >
> > > Given python is our most important dependency I'd like to propose that
> > any
> > > blender
> > > version we ship in the future (2.8+, 2.79x can keep doing what it's
> > doing)
> > > matches
> > > the official python recommendation for that version [1] so we have
> > maximum
> > > compatibility with any python addons
> > >
> > > 2) To support msvc 2017 we'll officially need a newer boost version,
> > sadly
> > > support
> > > for the latest is only available in 1.66 and i have not tested yet if
> all
> > > our
> > > dependencies can actually build against it. However we have no failing
> > > tests when
> > > building blender with boost 1.60+2017. it is just a bit (212 warns)
> > chatty
> > > with
> > > unknown compiler warnings, we could possibly repress these.
> > >
> > > 3) We recently added a switch in cmake to force the compiler to read
> all
> > > our code
> > > as utf-8 (since there were some users on other codepages that got
> > compiler
> > > errors
> > > on some utf8 strings) this added 290 C4828 compiler warnings to a full
> > > blender build.
> > > not great. None of these originate in our code, they are dragged in
> > though
> > > 3rd party
> > > headers.
> > >
> > > 10 in extern/bullet (we can probably fix these)
> > > 19 in lib/boost (this one is fixed in newer boost versions [2])
> > > 261 in lib/OpenCollada (we can easily send a pull upstream)
> > >
> > > however all of these are in comments, completely repressing C4828 might
> > > not be the
> > > worst thing here.
> > >
> > > 4) Libraries
> > >
> > > There's a library upgrade [3] coming up for OSL/LLVM/OIIO that just
> > > doesn't build on
> > > msvc2013.
> > >
> > > 5) Cuda
> > >
> > > Nvidia is notoriously slow with supporting newer msvc versions severely
> > > limiting the
> > > compiler versions we can use (cuda9 only supports 2017 RTM, and we're
> on
> > > update 5
> > > for msvc currently), to resolve this hostage situation I have created a
> > > small wrapper
> > > around nvrtc that's able to compile cycles [4], however nvidia doesn't
> > > allow nvrtc
> > > to create 32 bit cubins. which held me back from committing it.
> > >
> > > 6) 32 bit support
> > >
> > > I spend a fair amount of time building the blender deps in various
> > > formats, x86
> > > it starting to cost more and more time since a few of the projects just
> > > seem
> > > to test on linux, sometimes on windows/x64 but rarely on x86 leading to
> > > all kinds
> > > of obscure (usually sse) related build errors. This is starting to take
> > up
> > > a
> > > significant amount of my time for only a small percentage of end users
> > > (last
> > > time I asked ~15% of the blender downloads were for 32 bit users) and
> by
> > > the
> > > time we release 2.8 this number will probably have dropped even
> further.
> > >
> > > Proposal:
> > >
> > > Officially drop msvc 2013 support for master/2.80 and make vs2017.5 the
> > > new standard.
> > >
> > > 1) Land D2913, I had been dragging my heels on this because of the
> > > breakage for x86
> > > but given brecht recently put out an email [5] saying we were going to
> > > drop support
> > > there's no reason not to apply this anymore.
> > >
> > > 2) Retire the 2013+2015 buildbots, and replace them with vs2017 based
> > > builds.
> > >
> > > 3) Block msvc2013 version in cmake
> > >
> > > 4) Remove the vc12 folders from svn
> > >
> > > 5) Silence the 'unknown compiler warning in our boost version'
> > >
> > > 6) Add C4828 to the ignored warning list.
> > >
> > > 7) Update the wiki build instructions.
> > >
> > > I can do most of these my self, but will probably need sergey to do no
> 2.
> > >
> > > Pushing my luck:
> > >
> > > Is it too soon to drop x86 support?
> > >
> > > Note that all of these changes are for master/2.80. any updates for
> 2.79
> > > a/b/c/etc
> > > will remain on msvc2013 with the current libraries.
> > >
> > > --Ray
> > >
> > > [1] https://wiki.python.org/moin/WindowsCompilers
> > > [2] https://github.com/boostorg/format/commit/
> > > 045c6f15b9f6ef654642906f458d26b584b0b4c9
> > > [3] https://developer.blender.org/D2915
> > > [4] https://developer.blender.org/D2913
> > > [5] https://lists.blender.org/pipermail/bf-committers/2018-
> > > January/049029.html
> > >
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Aaron Carlisle

Picture taker | Bit cruncher | Pixel pusher | Document writer | Artist
Project administrator for the Blender 3D Documentation Project
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
https://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list