[Bf-committers] Changes to Windows Compiler Support.

[Mike Erwin]

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