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" <[email protected]> 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 <[email protected]> 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 > > [email protected] > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
