Wrapping requires CMake ≥ 3.27 ($<LIST:JOIN>) but project declares minimum 3.22.1

[hjmjohnson]

ITK's declared cmake_minimum_required is 3.22.1, but Wrapping/macro_files/itk_auto_load_submodules.cmake silently requires CMake ≥ 3.27 since PR #5842 (merged 2026-03-05). Builds with CMake 3.22.1–3.26.x and ITK_WRAP_PYTHON=ON produce castxml input files with empty -I / -isystem / -D flags and fail to find module headers.

Root cause

PR #5842 / commit 7a59c6da41 ("BUG: Use module's interface include in wrapping's castxml") replaced configure-time string(REPLACE …) with generation-time generator expressions in the castxml include-file template. The new template uses three nested $<LIST:JOIN,$<LIST:TRANSFORM,$<TARGET_PROPERTY:…>,REPLACE,…>,\n> constructs at:

• Wrapping/macro_files/itk_auto_load_submodules.cmake:124 — INTERFACE_INCLUDE_DIRECTORIES
• Wrapping/macro_files/itk_auto_load_submodules.cmake:128 — INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
• Wrapping/macro_files/itk_auto_load_submodules.cmake:132 — INTERFACE_COMPILE_DEFINITIONS

The $<LIST:JOIN,…> and $<LIST:TRANSFORM,…> generator expressions were first released in CMake 3.27 (2023-07). The corresponding list(JOIN …) / list(TRANSFORM …) commands have been around since CMake 3.12, which likely caused the version requirement to be overlooked — the generator-expression equivalents are much newer.

On CMake < 3.27, file(GENERATE) evaluates these expressions to empty strings (no diagnostic by default), so the generated *.castxml.inc file has no include flags and castxml fails when wrapping any module that depends on ITK module includes.

Reproducer

# Any environment with cmake 3.22.1 .. 3.26.x:
docker run -it ubuntu:22.04
apt update && apt install -y cmake build-essential git python3-dev
# cmake --version  →  3.22.1

git clone --depth 1 https://github.com/InsightSoftwareConsortium/ITK.git
cmake -S ITK -B build -DBUILD_TESTING=OFF -DITK_WRAP_PYTHON=ON
cmake --build build
# Wrapping fails: castxml cannot find ITK module headers because the generated
# *.castxml.inc files contain no -I / -isystem / -D flags.

Same symptom currently affects pixi-based builds where pixi.lock resolves CMake to 3.26.x.

Fix options

1. Bump Wrapping/CMakeLists.txt to cmake_minimum_required(VERSION 3.27). Smallest blast radius — ITK proper still builds with 3.22.1, only Python wrapping requires 3.27. This matches reality (most ITK consumers don't wrap from source) and is consistent with the Ubuntu 22.04 LTS rationale for the project-wide 3.22.1 floor.

2. Bump the project-wide cmake_minimum_required to 3.27. Cleanest, but pushes Ubuntu 22.04 LTS users (apt default cmake = 3.22.1, support until 2027) and RHEL 9 / Rocky 9 / Alma 9 users (cmake = 3.26.5) onto the Kitware apt repo or a manual install.

3. Revert PR Refactor wrapping to use target properties and address bug building remote modules against an ITK build directory #5842 to the configure-time string(REPLACE) form. Restores 3.22.1 compatibility but reintroduces the original bug (wrong include propagation when building remote modules against an ITK build directory).

4. Rewrite the three generator expressions using only pre-3.27 primitives (e.g. resolve the target property at configure time and emit the joined string into configure_file(... @ONLY) or a custom command). More invasive; reopens the original PR Refactor wrapping to use target properties and address bug building remote modules against an ITK build directory #5842 design discussion.

Option 1 is the minimum-disruption fix.

References

• Introducing commit: 7a59c6da41 (2026-02-26)
• Introducing PR: #5842 — Refactor wrapping to use target properties and address bug building remote modules against an ITK build directory
• CMake 3.27 release notes — $<LIST:…> operators: https://cmake.org/cmake/help/v3.27/release/3.27.html
• Current cmake_minimum_required(VERSION 3.22.1...3.29.0) declared in CMakeLists.txt
• Most-recently-bumped-the-floor commit: 2fd36ab3a6 (2024-12-19, 3.16.3 → 3.22.1)

[blowekamp]

I vote for option 1 to bump the required cmake version only for wrapping. The general user of ITK Python will be downloading a binary distribution and not building ITK Python from the source.

Update Looks like the modification for compatibility is actually better and easier to understand.