ci(ubuntu22): drop the apt.kitware.com CMake upgrade step

[Fedr]

Summary

Two-file change that replaces the apt.kitware.com CMake-upgrade step on Ubuntu 22.04 with a CMake-version-aware fallback in ConfigureCuda.cmake:

• docker/ubuntu22Dockerfile — delete the apt remove cmake → apt-add-repository apt.kitware.com → apt install cmake block entirely. Image now uses Ubuntu 22.04 jammy's apt-supplied CMake 3.22 directly, matching docker/ubuntu24Dockerfile's existing pattern (which ships 3.28 and never needed an upgrade).
• cmake/Modules/ConfigureCuda.cmake — gate CMAKE_CUDA_STANDARD on the running CMake version so CUDA20 is only requested when CMake actually supports the -std=c++20 flag for NVCC:

ELSE()
  IF(CMAKE_VERSION VERSION_LESS 3.25.2)
    set(CMAKE_CUDA_STANDARD 17)
  ELSE()
    set(CMAKE_CUDA_STANDARD 20)
  ENDIF()
  find_package(CUDAToolkit 12 REQUIRED)
ENDIF()

Why 3.25.2

CMake's NVCC flag table entry for -std=c++20 was backported into the CMake 3.25.2 patch release (gated on CUDA_COMPILER_VERSION >= 12.0). Earlier 3.25.x / 3.24 / 3.22 / … refuse with

Target "cmTC_*" requires the language dialect "CUDA20" (with compiler
extensions), but CMake does not know the compile flags to use to enable it.
Call Stack:
  source/MRCuda/CMakeLists.txt:4 (project)

Verified at the source by reading Modules/Compiler/NVIDIA-CUDA.cmake @ v3.25.2:

if (NOT CMAKE_CUDA_COMPILER_VERSION VERSION_LESS 12.0)
  set(CMAKE_CUDA20_STANDARD_COMPILE_OPTION "-std=c++20")
  set(CMAKE_CUDA20_EXTENSION_COMPILE_OPTION "-std=c++20")
endif()

Cross-checked with the 3.25 release notes:

CUDA language level 20 (corresponding to C++20) is now supported with NVCC 12.0 and above.

Ubuntu 22.04 jammy ships CMake 3.22 via apt, well below this threshold; hence the historical Dockerfile upgrade. Falling back to CUDA17 on that specific environment — and only that one — is the minimum change that restores a clean install.

Per-platform effect

Environment	CMake version	CUDA_STANDARD before	CUDA_STANDARD after
Ubuntu 22.04 apt	3.22	20 (would silently fail without Kitware upgrade)	17 (fallback)
Ubuntu 24.04 apt	3.28	20	20 (unchanged)
macOS Homebrew	latest	20	20 (unchanged)
Rocky Linux vcpkg	vcpkg toolchain	20	20 (unchanged)
Emscripten Docker	recent Kitware apt	20	20 (unchanged)
Windows	any	17 (separately pinned on line 6 for a different reason)	17 (unchanged)

Only Ubuntu 22.04 flips CUDA standard. Every other leg keeps CUDA20 as before.

Why not just keep the upgrade

Two separate exploration PRs close in favour of this one:

• #5962 swapped apt.kitware.com → GitHub Releases tarball (cmake-4.3.2-linux-<arch>.tar.gz). Works, but installs CMake 4.3.2 we don't functionally need (MeshLib's real floor is 3.22, not 3.28 or 4.x — only the NVCC+C++20 combination needed ≥ 3.25.2).
• #5965 wraps the existing Kitware recipe in a retry loop. Works, but keeps the single-origin dependency on a repo that's been repeatedly flaky (Dec 2024 outage, connection-refused on arm64 runners).

Dropping the upgrade entirely and falling back to C++17 on the one environment that needs it is the smallest durable change.

Verified on CI — run 24828203407

All four Ubuntu 22.04 matrix legs:

Job	Duration	Status
prepare-image / linux-image-build-upload (ubuntu22, x64)	14 m 03 s	✓
prepare-image / linux-image-build-upload (ubuntu22, arm64)	22 m 49 s	✓
ubuntu-arm64-build-test (ubuntu22, Release)	25 m 04 s	✓
ubuntu-x64-build-test (ubuntu22, Release, GCC-12)	43 m 32 s	✓

Specifically verified on that run:

• 0 references to apt.kitware.com or kitware-archive-keyring in the ubuntu22 image-build log — the step is fully gone.
• CUDA 12.6.85 identified, no does not know the compile flags error — the CUDA17 fallback fired silently and MRCuda configured cleanly against Ubuntu's CMake 3.22.
• All 283 unit tests passed, including CompressSphereToZip and CompressManySmallFilesToZip — nothing downstream regressed from dropping CUDA20 to CUDA17 in MRCuda.

The other matrix legs (Ubuntu 24.04, macOS, Windows, linux-vcpkg, Emscripten) are all on CMake ≥ 3.25.2 and continue to use CUDA20 unchanged.

🤖 Generated with Claude Code

[Fedr]

Closing: my "3.22 is enough" analysis missed a silent CMake-version requirement.

source/MRCuda/CMakeLists.txt configures CUDA_STANDARD 20, and the image's NVCC is 12.6.85 (-- The CUDA compiler identification is NVIDIA 12.6.85). CMake 3.22's NVCC-flag table has no entry for that combination:

CMake Error in /__w/MeshLib/MeshLib/build/Release/CMakeFiles/CMakeTmp/CMakeLists.txt:
  Target "cmTC_c5d22" requires the language dialect "CUDA20" (with compiler extensions),
  but CMake does not know the compile flags to use to enable it.
Call Stack:
  source/MRCuda/CMakeLists.txt:4 (project)

(Seen on run 24821677923.)

So the upgrade to a newer CMake was functionally required after all — just not captured in any cmake_minimum_required(...) line in the tree, which is what I checked. The right framing for the apt.kitware.com reliability problem is PR #5962 (swap to GitHub Releases tarball for Kitware's same CMake). I'll push that through instead.

[Fedr]

Reopened after pairing the Dockerfile change with the CUDA-standard fallback it needs.

Added commit a47a6a16: cmake/Modules/ConfigureCuda.cmake now picks CMAKE_CUDA_STANDARD based on the running CMake version:

IF(CMAKE_VERSION VERSION_LESS 3.26)
  set(CMAKE_CUDA_STANDARD 17)
ELSE()
  set(CMAKE_CUDA_STANDARD 20)
ENDIF()

Why 3.26: that's where CMake's NVCC flag table first learned -std=c++20 (gated on NVCC >= 12.0), verified at the source by reading Modules/Compiler/NVIDIA-CUDA.cmake@v3.25.0 (no CUDA20 entry) vs @v3.26.0 (CUDA20 entry added). CMake 3.22 (Ubuntu 22.04 jammy) is below that threshold and produced the does not know the compile flags failure that originally closed this PR.

Platform fallout:

• Ubuntu 22.04 — CMake 3.22 → now falls back to CUDA17 (builds cleanly; MeshLib's CUDA sources don't require C++20 features).
• Ubuntu 24.04 — CMake 3.28 → keeps using CUDA20 as before.
• macOS / Emscripten / vcpkg toolchains / anyone on recent CMake — unchanged, CUDA20.
• Windows path — untouched (already pinned to CUDA17 at line 6 for a different reason).

Expected next run: Ubuntu 22.04 image builds and the Ubuntu 22.04 arm64/x64 build-test legs configure successfully with neither the Kitware apt block nor a CMake upgrade in the image.