[Bf-committers] Changes to Windows Compiler Support.

[Danrae Pray]

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
>