[Bf-committers] Changes to Windows Compiler Support.

Sat Jan 27 06:12:54 CET 2018

I fully agree it’s about time to drop the old and focus most/all resources
on the new

On Sat, Jan 27, 2018 at 3:38 AM, Aaron Carlisle <carlisle.b3d at gmail.com>
wrote:

> +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
>
>