Migrate to rattler-build with staged outputs (refresh of #171 for 1.28.0)

[hmaarrfk]

Refresh of #171 by @cbourjau against the current 1.28.0 feedstock. All credit for the rattler-build "megabuild" design goes to Christian — this branch cherry-picks his commits (with original authorship) and rebases the effort onto today's main.

Status: CI is fully green — all 14 build jobs pass (linux_64/aarch64 × CPU/novec/CUDA 12.9/13.0, win × CPU/novec/CUDA 12.9/13.0, osx_arm64 × regular/novec).

What was done

Cherry-picked from #171 (44 commits): the full rattler-build migration — staged onnxruntime-build output whose build cache is shared by the -cpp and per-python outputs, nushell build scripts, and all of Christian's CUDA/cross-compilation/Windows fixes.

Dropped from #171:

• The three rerender commits (recipe edits bundled inside them were preserved) — rerendered ourselves with conda-smithy 2026.8.9.
• Commits already absorbed into main: python 3.14 migration file, namespace runner labels, patch 0005, the osx_arm64: default provider change, and CI workflow hand-patches that rerendering regenerates.

Adaptation for 1.28.0 + ports from main:

• version 1.28.0 + sha256, patches 0006/0007 (onnx-less test guards new in 1.28.0)
• CoreML EP on osx-arm64 (1.26.0 with Coreml execution provider for osx #182): onnxruntime_USE_COREML=ON, nlohmann_json host dep, provider assert test, license additions
• Jetson Thor / sm110 (Support jetson thor (sm110) #190): 110-real in the Linux CUDA 13.0 arch list
• nvcc_threads=2 (-Donnxruntime_NVCC_THREADS=2, Windows CUDA OOM mitigation)
• Re-enabled the -novec variants Migrate to rattler-build with staged outputs ("Megabuild") #171 had skipped while debugging; required inherit: onnxruntime${{ suffix }}-build
• cmake <4 pin, dropped sympy run dep, __cuda run dep on the python output, extra.feedstock-name

Fixes found while driving CI green (details in the commit messages):

1. C++20: 1.28.0 enforces CMAKE_CXX_STANDARD >= 20; the C++17 module-scanning workaround from Migrate to rattler-build with staged outputs ("Megabuild") #171 is obsolete (upstream now sets CMAKE_CXX_SCAN_FOR_MODULES=OFF itself).
2. Windows nushell PATH: $env.PATH = $"...;($env.PATH)" mangles the Path list on Windows and made cl.exe unfindable in CUDA builds; prepend to $env.Path instead.
3. Per-platform CUDA arch lists (mirrors main's bld.bat): SM 100+ triggers broken CCCL clusterlaunchcontrol.h inline asm on Windows CUDA 12.9 (long is 32-bit under MSVC); SM 110 is Linux-only.
4. conda-forge gtest/gmock on osx: the vendored googletest's printers format chrono::time_point via std::format, needing float to_chars (macOS 13.4+) while the deployment target is 11.0 — same reason main keeps gmock in host.
5. Explicit per-variant license lists: the vendored _deps set differs per variant (e.g. nlohmann_json/googletest are not vendored on osx, kleidiai is ARM-only, microsoft_wil is win-only, googletest only exists when unit tests are built). Each entry is now conditioned on exactly the variants that vendor it, validated against CI packaging logs.

Notes for review

• Header layout change: the cmake-direct install flattens headers to include/onnxruntime/*.h (was include/onnxruntime/core/session/...). Downstream consumers of onnxruntime-cpp will see the new layout.
• cutlass/cudnn_frontend licenses are not shipped on CUDA builds (parity with main, which never shipped them); can be itemized later.
• The megabuild works as intended: one CI job per platform/CUDA/suffix builds cpp + all of py310–py314 from a single shared cmake cache.

Supersedes #171 (kept as reference; happy to hand this back to @cbourjau's branch instead if preferred).

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

• ℹ️ output 0 output overrides versions pinned in the feedstock:
  ['- In section host: python 3.13.*']
  Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.
• ℹ️ License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found conda-forge.org > Docs > Maintainer Documentation > Contributing packages > SPDX Identifiers and Expressions.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/31292524604. Examine the logs at this URL for more detail.}

[cbourjau]

Thanks for pushing this forward! Are you aware that upstream introduced an execution provider plugin system which should decouple the expensive cuda builds from the Python version, AFAIU.

[hmaarrfk]

I think I remember you mentioning that.

But I did not look into it too deeply.

What would it change in terms of organization here?

[hmaarrfk]

Also. Full disclosure. I am trying to help here and threw my AI at your improvements since it is better than me at these problems.

I didn’t have time to explicitly write that at the top level but I have my AI often disclose itself in every commit.

I have not yet reviewed these changes.

[cbourjau]

I think I remember you mentioning that.

But I did not look into it too deeply.

What would it change in terms of organization here?

It would virtually remove the need for staged outputs, I think. We would compile one Python-independent cuda package per platform, and N fairly cheap Python-dependent frontends that depend on the former.