+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 <r...@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@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
