[antonwolfy]

This PR moves the setup that the nine pybind11 extensions in dpnp/backend/extensions repeat into one CMake function, and raises the minimum CMake version so the workarounds for older versions can be removed. It is stacked on #3104 and will be rebased onto master once that PR is merged.

1. Require CMake 3.27. cmake_minimum_required(VERSION 3.21...3.27) claimed that CMake 3.21 was enough, but pyproject.toml and the conda recipes already require CMake 3.31.6 or newer, and FetchContent_Declare(... FIND_PACKAGE_ARGS) for pybind11 needs at least 3.24. The minimum is now 3.27, which removes the 11 copies of the Windows workaround for target_link_options in CMake older than 3.27. The policy level stays at 3.27, as builds use today, so no CMake policy changes behavior.
2. Shared helper. The nine extension CMakeLists.txt files repeated about 80 identical lines: the pybind11 module, SYCL, the _usmarray dependency, fat-binary options, include directories, math flags, device code split, coverage, the redistribution rpath and install. build_dpnp_pybind11_ext in dpnp/CMakeLists.txt now does this. Each extension lists its sources and extra include directories, keeps its own oneMKL/oneMath linking, and passes LARGE_RANGES when its kernels can be launched over more than INT_MAX work-items (indexing, statistics, ufunc, window), which adds -fno-sycl-id-queries-fit-in-int at compile and link time. A new extension can no longer miss one of these options by copying an outdated file.

The only change in the generated build is for the vm extension: it had no fat-binary block, so it was the one extension built without -fsycl-targets when DPNP_TARGET_CUDA, DPNP_TARGET_HIP or DPNP_SYCL_TARGETS is set. It now gets these options like the others. vm compiles no kernels of its own, and in CUDA/HIP builds it compiles only vm_py.cpp and the two shared elementwise helper sources that ufunc already compiles with these options.

Verification. The project was configured with CMake 4.4.4, Ninja and icpx 2026.1, with and without this change on top of the same base, and every compile and link command (ninja -t commands and compile_commands.json), the generated install rules and the configure warnings were compared:

Configuration	Result
Release (oneMKL)	identical
Coverage with DPNP_GENERATE_COVERAGE, DPNP_WITH_REDIST and DPNP_SYCL_TARGETS=spir64-unknown-unknown	identical, except -fsycl-targets on the vm compile and link commands
Release with DPNP_USE_ONEMATH=ON	identical

Windows builds are covered by CI.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/index.html

[github-actions]

Array API standard conformance tests for dpnp=0.21.0dev16=np2py314h8d9cdd5_9 ran successfully.
Passed: 1491
Failed: 0
Skipped: 6

[coveralls]

Coverage is 82.64% — cmake-extension-helper into master. No base build found for master.

[vlad-perevezentsev]

LGTM
Thank you @antonwolfy