Align conda-recipe-cf and its CI with the conda-forge feedstock

[antonwolfy]

This PR makes the conda-forge-only CI (conda-package-cf.yml + conda-recipe-cf/) build mkl_umath the same way conda-forge/mkl_umath-feedstock does, so problems the feedstock would hit show up here first.

Changes

Fail on overlinking

• Pass --error-overlinking to conda build on Linux and Windows (the feedstock sets conda_build: error_overlinking: true).
• Add missing_dso_whitelist: $RPATH/mkl_umath_loops.dll # [win], as in the feedstock. That DLL is the only overlinking hit across all 14 build jobs of the latest main run (every Windows job; Linux is clean).

Build against the same NumPy as the feedstock

• Build matrix: NumPy 2.4 for py3.11 and 2.5 for py3.12–3.15 including 3.14t (was 2.3). py3.10 stays on 2.2.
• Replace the numpy: '1.26.4' pin in conda_build_config.yaml with numpy: '2', as in conda-forge's global pinning. CI overrides it with --numpy; without a pin, a local conda build conda-recipe-cf falls back to conda-build's built-in NumPy 1.26 default, which gives a NumPy-1-only package and cannot be solved for py >= 3.13.

Run dependencies from run_exports, as in the feedstock

• Drop the pin_compatible('mkl' / 'numpy' / 'intel-cmplr-lib-rt') run lines and stop ignoring the numpy and llvm-openmp run_exports.
• Add intel-cmplr-lib-rt # [not osx] to host. Previously it reached the build env only as a dependency of another package, so its run dependency had no version.
• Ignore the dpcpp compiler run_exports on Linux, so the package no longer depends on dpcpp-cpp-rt there.
• Add numpy >=2 to run. mkl_umath picks its NumPy 1 or NumPy 2 loops at compile time (USE_NUMPY_2 in mkl_umath_loops.c.src), so a build against NumPy 2 must not run on NumPy 1.x: complex sign then returns NumPy 2 results, and on Windows NumPy 1.x has no int64 ldexp loops for the patcher to replace. numpy's run_exports alone would allow >=1.25,<3.

The numpy run dependency becomes numpy >=2 plus numpy >=1.25,<3 from run_exports (>=1.23,<3 on py3.11), so in effect >=2,<3 instead of >=2.3.5,<3. Judging by the feedstock's build logs, mkl and intel-cmplr-lib-rt are pinned >=2026.x,<2027 and llvm-openmp >=23.1.3.

Compilers

• Linux c_compiler_version / cxx_compiler_version 15 (was cxx_compiler_version: 14 only), as in conda-forge's global pinning.

Notes

• The feedstock passes with this configuration on Linux and Windows for py3.11–3.15. py3.10 and 3.14t are built only here, so those jobs have no feedstock evidence behind them yet.
• The feedstock's published 0.6.0 packages still allow NumPy 1.x (numpy >=1.25,<3); the numpy >=2 run requirement needs to go there as well.
• Running the whole test suite in the recipe (pytest --pyargs mkl_umath, as the feedstock does) is covered separately by Run the whole test suite in the conda recipes #283.
• No CHANGELOG entry, since this only changes CI.

[jharlow-intel]

Thanks, this looks good! The build and requirements sections now match the feedstock line for line, and turning on --error-overlinking with the same DLL allowlist means a feedstock break should show up here first. A couple of small things inline.

[jharlow-intel]

With pin_compatible gone, the numpy run dep now comes from numpy's run_exports, so the 3.12+ builds against 2.5 accept numpy >=1.25,<3 instead of >=2.3,<3. That's what the feedstock ships too, but the test jobs only install numpy>=2, which resolves to the newest, so nothing here exercises the low end. Worth adding one test leg pinned to the oldest numpy we claim (1.26.4 per pyproject)? A feedstock-only breakage at that end would then show up here as well.

[antonwolfy]

Good catch, the low end turned out to be broken, not just untested. USE_NUMPY_2 is set at compile time from the NumPy headers (mkl_umath_loops.c.src), so a build against NumPy 2 carries NumPy 2's complex sign and the int64 ldexp loops. I installed the published feedstock 0.6.0 build with NumPy 1.26.4 (py3.12) and 1.23.5 (py3.11) on Linux, and the complex sign tests fail: np.sign(3+4j) gives 0.6+0.8j instead of NumPy 1's 1+0j. On Windows, NumPy 1.x's ldexp only has int/long (32-bit) loops, so the patcher won't find a match for the int64 ones and patch_numpy_umath() raises. So instead of a NumPy 1 test job I added numpy >=2 to run: in 1111c31; together with the run_exports that gives >=2,<3. NumPy 2.0.2 passes the whole suite locally, so I didn't extend the matrix. The feedstock needs the same fix, I'll follow up there.

[jharlow-intel]

Nit: since the matrix always passes --numpy, dropping the 1.26.4 pin is fine for CI. But a plain local conda build conda-recipe-cf now falls back to conda-build's built-in numpy default (1.26), which gives a numpy-1-only package and isn't what the feedstock does. Could we put numpy: ['2'] here, matching conda-forge's global pinning? I believe the --numpy flag in CI would still take precedence.

[antonwolfy]

Agreed, done in 1111c31, same as conda-forge's global pinning. Checked with conda render: without --numpy, py3.12 now builds against 2.5 instead of 1.26.4, py3.13 resolves at all, and --numpy 2.4 still takes precedence.