Actually, on macOS, XCode is specifically tied to a version of macOS. There is a short period of time where a version of Xcode will overlap 2 versions of macOS (usually the current and one version back). So for me, still back on macOS Catalina (out of choice) I use Xcode 12.4 which also works on my macOS 11 Big Sur machine. Current Xcode version is 14.2 and ONLY works on macOS 12.5 and above. So I am locked out of the "official" Apple compilers without having to move up to a newer macOS. (That is a different conversation).
We also provided our own build machines for Azure (self hosted agents) and moving up compilers usually involves spending a few days updating those build machines with new versions of the libraries (all built using the new compilers). This used to be easy when Qt offered the offline installers but now I get to wait through the several gigabyte download on a dozen machines over a 100Mbps connection. And now I get the fun of building Qt 5.15.[3.4.5.6.7.8.9...] because those installers are not even around through the maintenance tools for open source developers. For the Visual Studio compilers, the same thing applies. First versions of any piece of software is usually a train wreck. I'm not into beta testing other peoples software, especially compilers. I'll wait till the dust settles before moving up. Again, for us it is a matter of finding a time when we are not crushed with deadlines to have the developer move up compilers, deal with all of the incompatibilities just introduced by said new compiler, and then get back to work. Like someone else said, it becomes inertia. Our tools work on a daily basis and any interruption to those tools becomes a productivity issue. Small productivity losses I can handle, losing multiple days to an "upgrade" just isn't on my list of things to do. I feel like dropping VS2017 support is a no-brainer. Dropping macOS Catalina support is also a no brainer. Not sure about VS2019 as according to https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019 the support will end in 2024 and has extended support until 2029. And that is assuming VS 2019 16.11 and nothing earlier. Just my 2 cents -- Mike Jackson On 1/23/23, 6:05 PM, "Interest on behalf of Thiago Macieira" <interest-boun...@qt-project.org on behalf of thiago.macie...@intel.com> wrote: On Monday, 23 January 2023 09:19:07 PST Scott Bloom wrote: > One of the limiting factors in general, is we would prefer NOT to have 2 > compilers with very different c++ support. There have a been a number of " > C++11/14/17 etc" that have been partially implemented on one, and not on > the other. Unfortunately, NOT always protected by the "version switch". > > The biggest one that hit me, is std::make_unique which didn't exist on g++ > but did on windows. So if used, when you go build on linux, you have to > clean up your code. There have been some others through the years. > > So in general, we try to keep their abilities as close as possible, Thank you Scott, but you've answered the inverse of my question. You're talking about the ability to write code given a compiler you can't move from and what one needs to do to keep that working. I am asking why people are staying with the older one, if the new one is available and shouldn't (in theory) produce a compatibility burden with already-compiled code. On Linux, people generally use the compiler that their Linux distribution offers and many of them don't upgrade to another GCC major version after the initial release (CentOS/RHEL with the devtoolset being a notable exception). This implies to us that if a Linux distribution from 2018 is still a valid development environment, then GCC 8 must work too. But on Windows and on macOS, the compiler updates are disconnected from the OS version. Hence the question: if you can install compiler version Y using the same mechanism you installed version X, why won't you? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
