ENH: Update vendored VNL to for/itk-vxl-master-7829892 (vnl_math:: deprecation + sqrteps fix)

[hjmjohnson]

Repoint ITK's vendored VNL to the protected isc/vxl branch for/itk-vxl-master-7829892, advancing the pin from for/itk-vxl-master-272c3f1. This brings in the vnl_math:: deprecation campaign, the sqrteps precision fix, and a vnl_error.h warning fix from the ITK fork of VXL.

Rebuilt on current main. The two prerequisites are now merged and present in the base: #6427 (decouple itk::Math from vnl_math) and #6430 (remove the default -Wno-deprecated). This PR no longer stacks on either — it is a clean re-vendor on top of them.

What's in this re-vendor (272c3f1 → 7829892)

• vnl_math:: deprecation campaign — the public vnl_math:: surface is now [[deprecated]] for external consumers, with the real implementations relocated to undeprecated internal namespaces (vnl_math::detail, vnl_math::numeric_predicates) that vnl uses internally. Macro-gated (default on) so consumers can opt out per-category. Covers:
  • numeric constants (pi, e, sqrt2, …)
  • isnan/isinf/isfinite/isnormal predicates
  • 14 numeric functions (angle_0_to_2pi, rnd, floor, ceil, sgn, sqr, cube, remainder_*, squared_magnitude, …)
  • std:: re-exports (max/min/cbrt/hypot) and vnl_huge_val
  • abs — nudges ITK users toward itk::Math::Absolute()
• sqrteps precision fix — 1.490116119384766e-08 → the exact power-of-two 0x1p-26.
• vnl_huge_val deprecation message correction — advises std::numeric_limits<T>::infinity() for floating-point T and std::numeric_limits<T>::max() for integral T (integral types have no infinity).
• vnl_error.h -Wunused-parameter fix — vnl_error_assert_int_range's parameter is unused under NDEBUG; now [[maybe_unused]]. This warning appeared in every TU that includes vnl_vector.h in Release CI builds.

Downstream validation

Built against a pixi/ccache testbed of open-source ITK consumers (ITK @ this vendored vnl). 11/11 buildable consumers compiled clean with no vnl-related breakage: elastix, SimpleITK, RTK, Cleaver, PerformanceBenchmarking, SimpleITKFilters, TractographyTRX, VkFFTBackend, ANTs, BRAINSTools (+ ITK itself). Slicer/SlicerExtensions are not buildable in that conda testbed for environment reasons orthogonal to vnl.

With #6427 merged, ITK's own headers no longer route through the now-deprecated vnl_math:: surface, so this vendored update does not reintroduce internal deprecation warnings.

Fork provenance

The pin targets the branch anchor for/itk-vxl-master-7829892 on InsightSoftwareConsortium/vxl — a protected branch, not a tag. The fork's overlay commits are anchored by branches only (a same-named branch and tag would make the ref ambiguous and break update-third-party.bash). See the fork-convention clarifications in #6432.

[hjmjohnson]

Repointed the pin fd75e8b → 7829892: same content plus a [[maybe_unused]] fix for the vnl_error.h:49 -Wunused-parameter warning that appeared in every Release TU (one of the two CI-failure causes). The remaining ARM warnings come from itkMath.h's own vnl_math:: uses and resolve when #6427 merges — merge order is #6427 first, then this PR.

[blowekamp]

@hjmjohnson What you are doing in ITK's forks is not following the documentation in the welcome. The documentation does not mention creating a tag. Also the SHA using in the branch name per the the documentation is suppose to be from the upstream.

I don't know if what is documented is the best procedure. I did have an issue trying to follow a the documentation in a fork where there was both a tag and a branch.

Please review the documentation, and refine the procedure we should do in ITK forks.

[hjmjohnson]

@hjmjohnson What you are doing in ITK's forks is not following the documentation in the welcome. The documentation does not mention creating a tag. Also the SHA using in the branch name per the the documentation is suppose to be from the upstream.

I don't know if what is documented is the best procedure. I did have an issue trying to follow a the documentation in a fork where there was both a tag and a branch.

Please review the documentation, and refine the procedure we should do in ITK forks.

I caught this in an earlier iteration, and I thought I had implemented a durable fix :(. Working through the entire tree looking for what I did wrong and trying a different, more aggressive durable fix.

See

• DOC: Clarify vendored third-party fork conventions #6432

[hjmjohnson]

Downstream build verification — built this exact PR head (574c34bf7a6, vendored vnl for/itk-vxl-master-7829892, on current main with #6427/#6430 merged) against an open-source consumer forest. All 11 buildable consumers compiled clean with the vnl_math:: deprecations live — no vnl-related breakage:

ITK, elastix, SimpleITK, RTK, Cleaver, PerformanceBenchmarking, SimpleITKFilters, TractographyTRX, VkFFTBackend, ANTs, BRAINSTools.

[dzenanz]

Looks good on a glance.

[dzenanz]

I thought that VNL would be put into ITK, and maintained there, without referencing any external repository. I now see it has to be this way, as VNL has very different style from ITK.

[hjmjohnson]

@dzenanz We may someday choose to put VXL directly in ITK (keep it in the Third party so it does not need to be formatted like itk) but for the moment I wanted to keep some git tracking so that as I uncover bugs/failures that should be on VXL/VXL that I can cherry-pick as a good citizen (not that ITK will be using VXL any more).

It was also a lot easier to the 100+ commits in vxl with tests and rollback capabilities rather than have 100 ITK prs :). This was an easy way to "bundle" 100+ commits into 2 ITK PR's (and only 2 merges).

========
This PR was a major milestone goal of mine. I have a laundry list of other "purges" and "cleanups" and "shift away from vxl's netlib (circa 1999 codebase). I am pretty sure that a large swath of the netlib code is not needed, or easily replaced.