Run GitHub action with all allowed configurations and cache the build result

[IvanaGyro]

Some bugs failing build proccesses are detected lately, e.g., #581, #582. The reason is that we only build the project in CI with only one configuration. We should build all accepted configurations with GitHub flow to catch build errors as soon as possible. Below are the combinations I suggest.

CPU:

HPTT	BLAS
enabled	OpenBLAS
enabled	MKL
disabled	OpenBLAS
disabled	MKL

CUDA:

CUTT	cuTENSOR	cuQuantum
enabled	enabled	enabled
enabled	enabled	disabled
enabled	disabled	enabled
enabled	disabled	disabled
disabled	enabled	enabled
disabled	enabled	disabled
disabled	disabled	enabled
disabled	disabled	disabled

Some CUTT features are hidden behind the cuTENSOR's or cuQuantum's feature flag, so we can't separate CUTT from the combinations above. In addition, we have different feature flags for cuTENSOR and cuQuantum in the codebase, so we can't expect the feature flag of cuTENSOR is always on when enabling cuQuanum's feature flag, even cuTENSOR is a dependency of cuQuantum.

[pcchen]

If cuTENSOR is a dependency of cuQuantum, they don't we enforce to enable cuTENSOR when we enable cuTENSOR?

Or we only have the option of cuQuantum. Use cannot enable/disalbe cuTENSOR.

[yingjerkao]

With CUTT removed, I think we are converging to have both cuTENSOR and cuQuantum as dependencies. I am trying to set up a self-hosted GPU runner to test out the GPU CI/CD.

[pcchen]

One scope note for this matrix: the CPU configs here (including the MKL rows) should run the test suite (ctest), not just build. Today CI builds+tests only with USE_MKL=OFF, so the MKL-specific code paths — e.g. the #ifdef UNI_MKL integer-Matmul fallback and the Gemm_Batch path in BlockUniTensor/BlockFermionicUniTensor::contract — are never exercised at runtime (the only MKL build is coverity-scan, which is a static scan). Recently reviewed PRs (#998/#1005, the #724 shared-block fix) touch exactly those MKL contract branches, and their regression gtests can only run under USE_MKL=OFF, so those branches are verified by -fsyntax-only at best.

Concretely, for each config in the matrix, the job should do cmake --build and ctest, so an MKL-only runtime regression is caught here rather than shipping. (Related: #855 tracks specific missing MKL-contract test coverage.)

Posted by Claude Code on behalf of @pcchen

[ianmccul]

Today it is possible to configure with cuTENSOR but no cuQUANTUM, but this causes some GPU tests to fail at runtime,

linalg_Test.gpu_BkFUt_Qr
Gesvd_truncate.gpu_flag_combinations
Rsvd.gpu_flag_combinations

If these do not have a fallback implementation then cuQUANTUM should be required. If they are optional features that Python does not care about then the tests should be gated to be skipped if cuQUANTUM is not configured.

[IvanaGyro]

Per #584, cuTENSOR and cuQuantum will always bundle with CUDA. We will not assure the build with CUDA but not cuTENSOR and cuQuantum will work. This is a decision balance with maintenance.

[IvanaGyro]

Final Configurations

cuTENSOR and cuQuantum are always enabled with CUDA. CUTT has been dropped. HPTT is always enabled.

Test

Debug presets enable Asan. All of them should test with Python 3.10 (pending), which is the lowest Python version we support now.

• debug-openblas-cpu (ctest runtime under debug-openblas-cpu/debug-mkl-cpu: per-suite timing breakdown, dominated by Lanczos/Arnoldi-family tests #1058)
• debug-mkl-cpu (pending)
• debug-openblas-cuda (self-hosted runner, ci(gpu): native self-hosted GPU build + test workflow #1044)

Build

All build tasks should cover all alive Python versions (3.10~3.14 now). Openblas for PyPI process, MKL (x64) for conda process.

• openblas-cpu (done)
• mkl-cpu (done)
• openblas-cuda (ci(release): publish cytnx-cuda GPU wheels to PyPI (nightly + stable) #1023)
• mkl-cuda (will not implement until migrating to conda-forge)