Drop support for Visual Studio 2017?

Niels_Dekker · April 26, 2022, 1:22pm

Microsoft is dropping “vs2017-win2016” from their hosted pipelines for Azure Pipelines. An attempt to use it to test elastix produced the following error message:

##[error]This is a scheduled windows-2016 brownout. The windows-2016 environment is deprecated and will be removed on April 1st, 2022. For more details, see Windows-2016 environment removal postponed until April 1st, 2022 · Issue #5238 · actions/runner-images · GitHub
,##[error]The remote provider was unable to process the request.

It was suggested to use windows-latest, windows-2022, or windows-2019, instead, but they don’t have Visual Studio 2017 installed anymore.

Would it be OK for ITK to then also drop VS2017 support?

Related to ITK/Documentation/SupportedCompilers.md at 4e812d60743a3ed7c09647e7f3f0e8498583c2da · InsightSoftwareConsortium/ITK · GitHub
and

github.com

InsightSoftwareConsortium/ITK/blob/4e812d60743a3ed7c09647e7f3f0e8498583c2da/CMake/itkCompilerChecks.cmake#L19-L23


      
          # Minimum compiler version check: Microsoft C/C++ >= 19.10 (MSVC 14.1, Visual Studio 15 2017)
          if (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" AND
              CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.10)
            message(FATAL_ERROR "Microsoft Visual Studio 2017 or later is required.")
          endif ()

blowekamp · April 26, 2022, 1:32pm

Microsoft Visual Studio 2017 is still the compiler for Python 3.7-3.10.
https://pythondev.readthedocs.io/windows.html#python-and-visual-studio-version-matrix

However this is not a good way to refer and document the required version because there is the name of the Visual Studio GUI/Application, and the version of the compiler toolset. New version of the MSVC application support and contain the compiler toolset from MSVC 2017.

This can be configured with CMake with something like:

          CTEST_CMAKE_GENERATOR: "Visual Studio 16 2019"
          CTEST_CMAKE_GENERATOR_TOOLSET: v141,host=x64

But they do contain the VS2017 compiler toolset, which can be configured as above.

matthew.brett · April 26, 2022, 1:35pm

We’re having that discussion over on Numpy at the moment, and we’re
enabling the 2017 (141) toolchain using the 2019 image:

More discussion on Conda-Forge:

github.com/conda-forge/conda-forge.github.io

Move to vc142 toolchain on windows

opened 12:38AM - 22 Apr 22 UTC

h-vetinari

## TL;DR Move to newer toolset because: * vc141 is disappearing in the CI of… many projects (due to the compiler where it's the default being EOL), leading to bitrot, breakage, and extra work (both upstream and in packaging) * ABI not hard-linked with OS as on unix * better performance & less bugs * it's trivial for conda-forge to keep a consistent toolchain * the set of users being broken by this change is either empty or very small (<- happy to be challenged on this) ## Background ### Visual Studio version vs. Toolset version The MSVC compiler comes in different versions (..., VS2015, VS2017, VS2019, VS2022); these compilers come with a default toolset, but are able to target older ones. E.g. VS2017 comes with vc141, but can target vc140 (the default toolset of VS2015). vc142 is the default toolset of VS2019. What is the toolset exactly? From the [docs](https://docs.microsoft.com/en-us/cpp/build/projects-and-build-systems-cpp?view=msvc-170#the-msvc-toolset): > The Microsoft C++ compiler, linker, standard libraries, and related utilities make up the MSVC compiler toolset. ### ABI compatibility Microsoft has been _extremely_ conservative with ABI-compatibility from VS2015-VS2022 (the story about `[[msvc::no_unique_address]]` is instructive for that), meaning that a given project can use the new compilers while using all the old binaries that flow into the build. The one [caveat](https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170) is that any library built with a given toolset version can only be consumed (e.g. linked) by a toolset version that's the same or newer. ### No OS coupling Furthermore, unlike on linux, the version / ABI of the compiler is not coupled as tightly to a distribution (mostly through the ABI of the libstdcxx that comes with the compiler). As such, changing the toolchain version does not affect which platforms a binary built by a given toolset will run on. ### VS2017 EOL & impact on open-source CI VS2017 has [reached](https://docs.microsoft.com/en-us/lifecycle/products/visual-studio-2017) EOL, and has been aggressively removed by microsoft from its public CIs (Azure & GHA), see previous [discussion](https://github.com/conda-forge/conda-forge.github.io/issues/1538). This is IMO both understandable (avoid maintaining 3 separate compilers), as well as not very impactful, due to the very strong ABI-compatibility between VS2017 and VS2019. As such, many open source projects using these CI providers have forcibly moved to VS2019, and in almost all cases, adopted its default toolset vc142 (it's possible to change, but presumably most maintainers don't know or don't care until an issue is raised). This means that compatibility with vc141 is bitrotting at an accelerated pace, because the respective CIs are not trying to compile against that anymore. LLVM 14+ also hard-requires vc142, and we have followed suit there already. This happened even to numpy (originally the 1.22.0 release was [not](https://github.com/conda-forge/numpy-feedstock/pull/248#issuecomment-977335517) compilable with the vc141 toolchain), and similar issues keep [cropping up](https://github.com/numpy/numpy/issues/21346). I argue that spending time on this has a bad cost/benefit, and the numpy devs voiced [interest](https://github.com/numpy/numpy/issues/21346#issuecomment-1101432000) in moving to vc142 as well, but mentioned the current restriction of conda-forge. Since I've already argued for this move in the context of the windows-2016 image [deprecation](https://github.com/conda-forge/conda-forge.github.io/issues/1538#issuecomment-964635070) and the numpy [1.22.rcs](https://github.com/conda-forge/numpy-feedstock/pull/248#issuecomment-980487868), I'm now (reluctantly) picking up the mantle for this, c.f. Isuru's [comment](https://github.com/conda-forge/numpy-feedstock/pull/248#issuecomment-991996501): > [...] until someone champions the move to vs2019 which means getting approval from core to move, announcing the move and giving time for users and then doing the switch itself. ## Impact ### On conda-forge packaging None. We have a consistent toolchain, and feedstocks upgrading to a new compiler can continue to use all previously built artefacts. That means we don't even need a migration, we can just switch to vs2019 in conda-smithy. ### On conda-forge users For the vast majority of users who just consume packages, there is no impact. The main [objection](https://github.com/conda-forge/conda-forge.github.io/issues/1538#issuecomment-964614978) to bumping the toolset version along with the image & compiler in was the impact on users that are using a conda-based environment to develop on windows, and have VS2017 installed. I claim (and would be happy to be challenged on this) that the set of affected users - i.e. who develop on windows using conda, aren't already directly or indirectly affected by CI providers dropping VS2017 (e.g. due to vc141-support bitrotting for their dependencies), and cannot upgrade to a 100% ABI-compatible, 1:1 drop-in & free compiler - is empty, or very very close to it. _If anyone would be affected by this (or knows someone who is), I'd really like to know the constraints of the situation, because I have trouble imagining what those could be._ ### Compatibility with mingw By default, vc142 emits some assembly sections that mingw [chokes](https://github.com/matthew-brett/dll_investigation/issues/1) on. However, this can be fixed with the addition of a single flag (`-d2VolatileMetadata-`). Given that the previous interaction was working only incidentally (cf. the following [comment](https://sourceforge.net/p/mingw-w64/mailman/message/37595771/) from upstream dev), this isn't a substantial change in circumstances: > Mixing static libraries or object files between mingw and msvc is not supported, and not expected to work, in general. You might have been lucky and your library might have been simple enough not to hit any problematic case though. ### Other * Many feedstocks are using VS2019(+vc142) already, this would harmonize things. * Many bugs fixed -> less compilation errors on windows * Better performance in some cases (e.g. for numpy, this would enable compiling down to instrinsics for `__popcnt`) ## In summary It's time to move on - the trade-offs for staying on vc141 are getting less and less justifiable by the day, the benefits are substantial (as time is the most precious resource in upstream & packaging), and the breakage (if any) is negligible.

Niels_Dekker · April 26, 2022, 2:06pm

Thanks @blowekamp but does that mean that ITK still needs to be built with the VS2017 toolset, v141? Would that be necessary for SimpleITK?

wiki.python.org - Which Microsoft Visual C++ compiler to use with a specific Python version suggests that any 14.X compiler should be fine for CPython 3.5 - 3.10. Right?

dzenanz · April 26, 2022, 2:52pm

While v141 toolset is desirable and maybe required, we can use v142 and VS2019 for CI builds and tests. I suggest we do that. I assume it is best to go from windows-2016 to windows-2022?

blowekamp · April 26, 2022, 3:11pm

We have released SimpleITK 2.2rc1, rc2 build with v141, and plan to release and maintain SimpleITK 2.2 with v141.

Yes, v142+ would likely work, but there may be some undetected bugs or other issues that would need to be addressed if changed.