[Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Thiago Macieira]

On domingo, 12 de fevereiro de 2017 21:41:16 PST Gunnar Roth wrote:
> vcblog says: " Specifically, VS 2015 and VS “15” will have the same major
> compiler version (19) and their STLs will be binary-compatible, and this
> compatible compiler and STL will remain available throughout the lifecycle
> of VS “15”.  This implies that the STL’s DLL will continue to be named
> msvcp140.dll.  (At some point in the future, we expect to have a compiler
> version 20 and a binary-incompatible STL again.)"

This needs to be tested. It's not only binary compatibility, it's also the way 
that Windows does DLLs -- especially the VC runtime ones. It's possible to 
load more than one with different manifest information, which by itself is 
problematic. But then you can't delete in one pointers new'ed by another, 
which is a much bigger problem.

Maybe that's fixed. Maybe it isn't. Someone who knows more about DLLs, 
manifests, and VC needs to check this

> > Maybe we ought to revisit that.
> 
> yes.

Let's discuss that when we're approaching 5.8.1 and 5.9.1.

> > The next problem is the load on the build servers and on the people doing
> > the testing that the generated binaries actually work. See the discussion
> > we had a couple of months ago on what we'd release for 5.8 and 5.9. We
> > need to keep the number of binaries to a constant number. So adding MSVC
> > 2017 would mean dropping something.
> 
> yes dropping vs2015 build as using the latest 19.xx compiler will be binary
> compatible to vs2015 code.

We can't drop it from the CI. I don't think we can drop it from the build 
packages either, since usually you compile with the oldest you plan to use. So 
if you're correct and VS2017 is binary-compatible, then we are already 
providing the packages for VS2017.

> > But we did make MSVC 2017 work with 5.8. We solved all build issues we
> > could find.
> 
> Well sadly that does not include 5.8.0, so now users have to wait at least
> until may to get a vs2017 ( which will be released on March 9th).

We had planned on having 5.8.1 before that release. Unfortunately, it's not 
going to happen, due to lack of resources. 5.8.1 is postponed indefinitely and 
will most likely not happen.

5.9.0 will have support and binaries.

> > How about asking Microsoft to follow up on their promise of keeping binary
> > compatibility instead? That way, the binaries built with MSVC 2017 will
> > work with 2018 and we don't have to rebuild.
> 
> How about Qt supports the binary compatibility bewegen cl19.00 and cl
> cl19.xx instead on making a win32-msvc2017? mkspec should be based on the
> cl major version , instead of the IDE year. QtCreator complains when you
> try to use a qt with 2017 mkspec and a 2015 compiler set.

The win32-msvcXXXX mkspecs have been dropped as of Qt 5.8.0. They're all now 
called "win32-msvc" and the actual versions are extracted from the compiler 
itself, to enable command-line options as needed. The plan was for 2017 to not 
get an mkspec of its own, but we had to add it for compatibility with Qt 
5.6.3, which apparently needed to get one of its own.

Though if you're right, we wouldn't have needed win32-msvc2017 and could have 
told people to use win32-msvc2015 instead. Except that users not as 
knowledgeable as you would have complained that the support wasn't final.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center