Windows wheel build for ITK 6.0b02 cannot wrap modules that include C++17-only ITK headers

Summary

The pre-built ITKPythonBuilds-windows.zip published with the v6.0b02 release ships a wrapping configuration that invokes castxml with -std:c++14. ITK 6.0b02 itself requires C++17 (see CMakeLists.txt, the explicit FATAL_ERROR for CMAKE_CXX_STANDARD < 17), and several public headers contain C++17-only syntax — most notably the class template argument deduction (CTAD) guide at Modules/Core/Common/include/itkArray.h:217:

template <typename TValue>
Array(TValue *, typename vnl_vector<TValue>::size_type, bool) -> Array<TValue>;

castxml invoked with -std:c++14 rejects this with error: a type specifier is required for all declarations, breaking every remote-module Python wheel build on Windows whose .cxx wrapping inputs transitively #include <itkArray.h> (which is essentially all of them).

Affected platforms / versions

• Host: windows-2022 GitHub Actions runner (and any equivalent MSVC environment)
• Pre-built archive: ITKPythonBuilds-windows.zip from v6.0b02
• ITK source: v6.0b02
• ITKPythonPackage: v6.0b02 (and tested with main HEAD 2b655cb931) — neither helps; this is a build-time-baked issue in the pre-built archive, not a wheel-build script issue.

Linux and macOS wheel builds for the same matrix are unaffected (their pre-built archives appear to use the project's CMAKE_CXX_STANDARD correctly).

Repro

In any ITK remote module's wheel-build workflow that uses ITKPythonBuilds v6.0b02:

env:
  itk-wheel-tag: v6.0b02
  itk-python-package-tag: v6.0b02   # or any newer commit on main

jobs:
  build-windows-opencl-python-packages:
    runs-on: windows-2022
    strategy:
      matrix:
        python-version-minor: ["10", "11"]
    steps:
      - uses: actions/checkout@v5
      - run: |
          curl -L "https://github.com/InsightSoftwareConsortium/ITKPythonBuilds/releases/download/${{ env.itk-wheel-tag }}/ITKPythonBuilds-windows.zip" -o ITKPythonBuilds-windows.zip
          7z x ITKPythonBuilds-windows.zip -o/c/P -aoa -r
          # ... build wheels via IPP/scripts/windows_build_module_wheels.py ...

This produces:

[NN/89] castxml.exe ... --castxml-cc-msvc ( ... -std:c++14 ) ... itkVkComplexToComplex1DFFTImageFilter.cxx
In file included from C:/P/IPP/ITK-win_311-x64/Wrapping/castxml_inputs/itkVkComplexToComplex1DFFTImageFilter.cxx:6:
C:/P/IPP/ITK-source/ITK/Modules/Core/Common/include/itkArray.h:217:1: error: a type specifier is required for all declarations
3 errors generated.
FAILED: [code=1] C:/P/IPP/ITK-win_311-x64/Wrapping/castxml_inputs/itkVkComplexToComplex1DFFTImageFilter.xml

Concrete log: https://github.com/InsightSoftwareConsortium/ITKVkFFTBackend/actions/runs/26223272896/job/77163539093 (job build-windows-opencl-python-packages (11) from ITKVkFFTBackend#74).

Root cause

Castxml is invoked by the add_custom_command written into the pre-built ITK install tree (C:/P/IPP/ITK-win_311-x64/Wrapping/castxml_inputs/*.castxml.inc). The compiler-driver flag list in those generated .inc files contains -std:c++14. The flag was injected at the time ITKPythonBuilds CI built ITK-win_311-x64 — i.e. that build was configured with CMAKE_CXX_STANDARD=14, even though ITK 6.0b02's top-level CMakeLists.txt requires >= 17.

The most likely culprit is the CI configuration that produces ITKPythonBuilds-windows.zip — it probably still passes (or defaults to) CMAKE_CXX_STANDARD=14. Linux and macOS variants of the archive either pass -std=c++17 or pick it up implicitly from a newer compiler default.

Proposed fix

Update whichever CI script builds the Windows half of ITKPythonBuilds so that CMAKE_CXX_STANDARD=17 (or higher) is passed when configuring ITK-win_*-x64. The propagated value will land in the generated castxml_inputs/*.castxml.inc and unblock all downstream remote-module wheel builds on Windows.

Affected file is likely one of:

• InsightSoftwareConsortium/ITKPythonBuilds/.github/workflows/build-windows-package.yml (or whatever Windows-build workflow drives the release tarball)
• The equivalent script in InsightSoftwareConsortium/ITKPythonPackage/scripts/internal/ if the build is delegated there

Re-tag and release as v6.0b03 (or a v6.0b02.postN) once the rebuilt zip is produced.

Workaround for affected modules

Until a fix is released, downstream remote modules can disable the Windows Python wheel job, e.g.:

build-windows-opencl-python-packages:
  if: false   # blocked on ITKPythonBuilds windows-zip castxml -std:c++17
  runs-on: windows-2022
  # ...

Linux and macOS wheel jobs remain functional after the Python-3.10+ build-script fixes that landed on ITKPythonPackage:main (PR #304 + a2d2a5fa "Bootstrap pip via ensurepip on Windows wheel build to fix Python 3.10+") — so module wheels can still ship for those platforms.

Additional context

• ITK source confirmation that C++17 is mandatory: https://github.com/InsightSoftwareConsortium/ITK/blob/v6.0b02/CMakeLists.txt — FATAL_ERROR when CMAKE_CXX_STANDARD < 17.
• The C++17 CTAD guide that breaks parsing: https://github.com/InsightSoftwareConsortium/ITK/blob/v6.0b02/Modules/Core/Common/include/itkArray.h#L217.
• Two C++17 constructs in ITK 6 that castxml-with-c++14 will reject — itkArray.h:217 is the first hit; expect to surface more once that one is fixed.
• ITKPythonBuilds main branch is dormant (HEAD bb6c9bab from 2017-06-14, "Add links in README") — the release-tag workflow is the only effective channel here.