Tracking: ITK_FUTURE_LEGACY_REMOVE / ITK_LEGACY_REMOVE build broken across opt-in (ingested remote) modules

[hjmjohnson]

Tracking issue for the ITK_FUTURE_LEGACY_REMOVE / ITK_LEGACY_REMOVE build fixes across the opt-in (ingested remote) modules. The Mac10.15-AppleClang-dbg nightly (CDash build 11368783) configures with ITK_FUTURE_LEGACY_REMOVE and failed to compile; investigating it surfaced that the deprecation-removal configurations are broken across many modules that no CI job exercises.

PRs (merge checklist)

• ENH: Extend itk::QRDecomposition and migrate in-tree vnl_qr consumers #6499 — Core/Common gtests, LandmarkBasedTransformInitializer, FEM: vnl_qr → Eigen-backed itk::QRDecomposition (+ Solve(matrix)/Inverse()), self-contained tqlrat, drop dead determ_
• COMP: Gate VXL eigensystem tests under ITK_FUTURE_LEGACY_REMOVE #6500 — VXL vnl_algo tests: gate the vnl_*_eigensystem tests under ITK_FUTURE_LEGACY_REMOVE (completes the eispack drop)
• COMP: Modernize deprecated macros in SmoothingRecursiveYvvGaussianFilter #6501 — SmoothingRecursiveYvvGaussianFilter: ITK_NOEXCEPT, itkTypeMacro, itkGetStaticConstMacro
• COMP: Modernize deprecated APIs in VariationalRegistration #6503 — VariationalRegistration: itkTypeMacro, iterator GetIndex(), CoordRepType
• COMP: Modernize deprecated macros in ingested filter/IO modules #6504 — Cuberille, FixedPointInverseDisplacementField, SubdivisionQuadEdgeMeshFilter, TotalVariation, IOMeshSTL, RANSAC: itkTypeMacro, iterator GetIndex()
• COMP: Modernize deprecated macros in ParabolicMorphology #6505 — ParabolicMorphology: itkTypeMacro, itkGetStaticConstMacro
• COMP: Modernize deprecated macros in HigherOrderAccurateGradient #6506 — HigherOrderAccurateGradient: itkTypeMacro, itkGetStaticConstMacro
• COMP: Replace deprecated iterator GetIndex() in ingested modules #6507 — IsotropicWavelets, MGHIO, PhaseSymmetry, MinimalPathExtraction: deprecated iterator GetIndex()
• COMP: Modernize deprecated macros in PrincipalComponentsAnalysis #6508 — PrincipalComponentsAnalysis: itkTypeMacro, itkStaticConstMacro

Follow-ups (not yet opened)

• Add an all-in-tree-modules ITK_FUTURE_LEGACY_REMOVE/ITK_LEGACY_REMOVE CI gate (extend the Mac10.15-AppleClang-dbg nightly to ITK_BUILD_ALL_MODULES) so this class of breakage is caught at PR time. Unblocked once the PRs above merge.
• Retire FEM LinearSystemWrapperItpack (dsrc2c.c, ~8k lines of f2c) for an Eigen-backed wrapper, then drop the co-located tqlrat.
• COMP: Remove non-functional CCACHE_BASEDIR setting from ITK_USE_CCACHE #6510 — Fix CMake/itkCCacheSupport.cmake: bake CCACHE_BASEDIR into the compiler launcher (the set(ENV{...}) was a configure-time no-op) so cross-build-tree cache reuse works

CI coverage gap. The only nightly that enables ITK_FUTURE_LEGACY_REMOVE (Mac10.15-AppleClang-dbg) builds only the default module set. The modules above are opt-in (ingested remote modules, EXCLUDE_FROM_DEFAULT), so they are exercised by no CI job under the legacy-removal flags — and the ITK_LEGACY_REMOVE-only configuration is not exercised at all. That is why this breakage accumulated undetected until the QR deprecation tripped the one default-module gate.

Root cause & mechanism

The deprecation guards are hard compile-time errors:

• ITK_FUTURE_LEGACY_REMOVE: itkTypeMacro / itkGetStaticConstMacro / itkStaticConstMacro become static_assert/string-literal errors (itkMacro.h); vnl/algo/vnl_qr.h and VNLSparseLUSolverTraits.h #error; vnl_*_eigensystem and the netlib eispack are dropped; ImageRegionIterator/ImageScanlineIterator::GetIndex() and the CoordRepType aliases are removed.
• ITK_LEGACY_REMOVE: ITK_NOEXCEPT is removed.

Because a #error/static_assert only fires when a translation unit that includes it is actually compiled, and these modules are never compiled under the legacy flags in CI, the breakage was invisible. The fixes are mechanical, behavior-preserving modernizations to the replacement APIs the deprecation messages point to (itkOverrideGetNameOfClassMacro, Self::name, static constexpr, ImageRegionIteratorWithIndex, CoordinateType, noexcept, itk::QRDecomposition).

Verification

Each PR was built under baseline, ITK_LEGACY_REMOVE=ON, and ITK_LEGACY_REMOVE=ON + ITK_FUTURE_LEGACY_REMOVE=ON, with the module's tests run in baseline (no behavior change). The IsotropicWavelets ShrinkDecimate/ExpandWithZeros scanline→ImageRegionIteratorWithIndex refactor and the FEM/LandmarkBased vnl_qr→itk::QRDecomposition migrations were additionally verified for numerical equivalence.

[dzenanz]

I don't remember ever encountering an application which uses ITK's FEM. Maybe we can deprecate FEM entirely?

[hjmjohnson]

I don't remember ever encountering an application that uses ITK's FEM. Maybe we can deprecate FEM entirely?

@dzenanz I am supportive of that! I also could find no evidence of it being used. I'm proposing an agressive "minimize developer burden" plan and am very willing to do a more gradual approach.

1. Move FEM to a remote module NOW (add Modules/Remote/FEM.remote.cmake), but have it only as a breadcrumb no-op with loud warnings and messaging.
2. Indicate that FEM is slated for complete removal in ITK 7, and give very LOUD WARNING "if you use this, update an ITK issue #XXXXX so we know its utility. FEM support will be removed in will be removed" message if activated.
3. make a note that the FEM.remote.cmake is not maintained or updated after 7/1/2026, and that inclusion here is ONLY to verify that this component is not needed by an unknown ITK user.
4. Remove Modules/Remote/FEM.remote.cmake in ITKv7.

==
We could go through a long deprecation process, but that is quite a bit of work for something that we really think is not used anywhere. The ROI seems very low. Being clear that "we can restore if use case is found" is low effort until proven that effort is needed.

[dzenanz]

I am totally in favor of the approach you just proposed!