BNGSIM_KLU_AUTOBUILD cannot complete on a bare Linux host: SuiteSparse_config requires a BLAS, so REQUIRE_KLU=ON makes a source install a hard configure failure

[wshlavacek]

Summary

BNGSIM_KLU_AUTOBUILD (GH #209, CMakeLists.txt:76) exists so that an install on
a box with no system SuiteSparse still gets the sparse solver instead of failing
or degrading to dense. On a bare ubuntu-latest it cannot complete: the
pinned SuiteSparse subset's own CMake calls find_package(BLAS), the runner
image has no BLAS, and the configure dies in SuiteSparse_config before KLU is
reached at all.

Combined with BNGSIM_REQUIRE_KLU = "ON" — which pyproject.toml sets for
every scikit-build-core build — the net effect is that
pip install . / pip install <sdist> is a hard configure failure ~12 s in
on a stock Linux host with no SuiteSparse. Not a dense-only fallback; a build
error.

So GH #209's self-sufficiency property holds on macOS (Accelerate supplies the
BLAS) and does not hold on Linux.

Found by #169's new whole-suite Linux job on its first run, before any test ran.

Evidence

Run 31022147818,
ubuntu-latest leg. The autobuild fires and reports itself normally:

-- BNGsim: SuiteSparse/KLU not found — building the pinned KLU subset from source
 into .../build/cp312-cp312-linux_x86_64/_bngsim_klu_autobuild (one-time, ~1-2 min) …
==> Building SuiteSparse v7.8.3 (d3c4926d2c47fd6ae558e898bfc072ade210a2a1)

SuiteSparse_config then walks its whole BLAS probe list and finds nothing:

-- Looking for Intel 32-bit BLAS -- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Looking for 32-bit Apple BLAS -- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Looking for ARM 32-bit BLAS -- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Looking for IBM ESSL 32-bit BLAS -- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Looking for 32-bit OpenBLAS -- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Looking for 32-bit FLAME (BLIS) BLAS -- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Looking for any 32-bit BLAS
-- Looking for sgemm_ - not found
-- Configuring incomplete, errors occurred!

_bngsim_autobuild_klu handles the non-zero exit exactly as written
(CMakeLists.txt:223-226) and hands back to discovery:

-- BNGsim: SuiteSparse/KLU auto-build FAILED (exit 1); see the output above.
 Falling back to system discovery result.

…at which point _bngsim_require_klu_or_die (CMakeLists.txt:154, called from
:372) turns the still-missing KLU into the fatal error:

CMake Error at CMakeLists.txt:154 (message):
 SuiteSparse/KLU is required (-DBNGSIM_REQUIRE_KLU=ON) but was not found/usable:
 not found on any search prefix.

Full call stack of the underlying failure:

FindPackageHandleStandardArgs.cmake:233 (message)
 FindBLAS.cmake:1419 (find_package_handle_standard_args)
 SuiteSparse_config/cmake_modules/SuiteSparseBLAS.cmake:242 (find_package)
 SuiteSparse_config/CMakeLists.txt:130 (include)

What is notable about it

KLU itself does not use a BLAS. It is a sparse LU with a
BTF/AMD/COLAMD/CAMD preordering; the dense-blocked SuiteSparse packages
(CHOLMOD, UMFPACK, SPQR) are the ones that need one. The dependency comes from
SuiteSparse_config — the shared configuration package every SuiteSparse
component includes — probing unconditionally. So the thing blocking the build is
not something the KLU subset needs at runtime.

That is what makes this look fixable at the ci/build_suitesparse.sh level
rather than by adding a BLAS dependency to bngsim: if SuiteSparse_config can be
configured without a BLAS (or pointed at a stub), the subset that bngsim actually
consumes is unaffected. I have not verified which SuiteSparse option does that,
so treat this paragraph as a direction, not a fix.

The failure is also silent to every existing CI job, which is why it survived:

job	why it cannot see this
wheels.yml (all three OSes)	resolves a prebuilt SuiteSparse through SUITESPARSE_ROOT (dnf install suitesparse-devel on Linux, ci/build_suitesparse.sh with an explicit prefix on macOS/Windows), so the autobuild branch is never taken
mir.yml, windows-tail.yml, windows-nfsim.yml, native-tests.yml	all build -DBNGSIM_ENABLE_KLU=OFF
local development	macOS, where Accelerate satisfies the probe

python-tests.yml's macOS leg is now the only place the autobuild path runs at
all, and it is the platform where it works.

Impact

• A stock Linux pip install bngsim from sdist fails to build unless the
  user has SuiteSparse (or a BLAS) already. Note the published wheels are
  unaffected — they bundle KLU — so this hits source installs: HPC modules,
  conda-less clusters, pip install --no-binary, aarch64 and musllinux (which
  cibuildwheel skips), and Python versions outside cp310-cp313.
• The error message is at least actionable: it names apt-get install libsuitesparse-dev and the -D escape hatches. So this is a
  "self-sufficiency claim is overstated" bug, not a mystifying one.

Workaround in place

#169's Linux leg installs libsuitesparse-dev
(PR #175), the same system-package
route cibuildwheel's Linux leg already takes, so it matches the shipped wheel.
macOS deliberately installs nothing so that leg keeps exercising the autobuild.
Neither change touches the autobuild itself — this is unfixed.

Suggested acceptance

A Linux host with no SuiteSparse and no BLAS can pip install . and get
HAS_KLU True. The cheap CI proof is a leg that does not install
libsuitesparse-dev — i.e. deleting the workaround step from
python-tests.yml and staying green.