blas-src

blas-src solves a specific problem in the Rust numerical computing ecosystem: crates that call BLAS routines need a concrete linear algebra implementation linked into the final binary, but which implementation is available or preferred varies by platform and deployment target. Rather than hard-coding one, blas-src exposes Cargo features — accelerate, blis, four intel-mkl threading/linking variants, netlib, openblas, and r — each of which pulls in a small companion -src crate (accelerate-src, blis-src, intel-mkl-src, netlib-src, openblas-src, r-src) that builds and links the actual library. The crate itself is a #![no_std] shim: it re-exports whichever backend is chosen as extern crate raw, so downstream crates like blas can compile against one implementation without writing any conditional logic of their own.

A build.rs check enforces that at most one backend feature is enabled at a time, since linking two BLAS implementations into the same binary would conflict. This makes blas-src the standard glue crate in the blas-lapack-rs organization’s ecosystem (alongside blas, lapack-src, and lapacke), letting scientific and machine-learning crates in Rust depend on “a BLAS” abstractly and defer the concrete choice to the application author.

What You Get

• Interchangeable BLAS backends behind one Cargo feature flag: accelerate, blis, four intel-mkl linking/threading variants, netlib, openblas, and r
• A no_std shim crate with no runtime code of its own — it only re-exports the chosen backend under a common name
• A build.rs guard that fails the build at compile time if more than one BLAS backend feature is accidentally enabled
• Drop-in compatibility with the blas crate and the rest of the blas-lapack-rs ecosystem (lapack-src, lapacke)

Common Use Cases

• Scientific computing crates that need linear algebra without dictating which BLAS library the end user must install
• macOS-targeted builds that want the system Accelerate framework instead of building OpenBLAS from source
• CI pipelines that swap in the netlib reference implementation for fast, deterministic test builds
• Cross-platform ML/numerics libraries that let downstream users pick a hardware-optimized backend like Intel MKL

Under The Hood

Architecture The crate is intentionally minimal: src/lib.rs is a #![no_std] module consisting entirely of feature-gated extern crate ... as raw; statements, one per supported backend, so exactly one concrete BLAS implementation is re-exported as raw for downstream crates to link against. The only other logic lives in build.rs, which counts how many CARGO_FEATURE_* variables are set for the six backend families and panics if more than one is active, preventing a double-link failure at the linker stage rather than leaving it as a runtime surprise. There is no runtime behavior, state, or data flow beyond this compile-time backend selection — the crate’s entire job is to be a stable, zero-cost indirection point that the rest of the blas-lapack-rs ecosystem (blas, lapack-src, lapacke) can depend on abstractly.

Tech Stack blas-src is pure Rust (2021 edition) with zero required dependencies; every dependency (accelerate-src, blis-src, intel-mkl-src, netlib-src, openblas-src, r-src) is declared optional = true and gated behind its matching Cargo feature, so a consumer only pulls in the one backend crate it selects. intel-mkl-src is further split into four features covering the static/dynamic and parallel/sequential linking combinations that Intel MKL supports. Documentation is published to docs.rs with a [package.metadata.docs.rs] changelog pointer, and CI (GitHub Actions) runs cargo clippy -D warnings and cargo fmt --check plus a per-backend build/test matrix across macOS and Ubuntu runners.

Code Quality No dedicated unit or integration test files exist in the repository; the CI matrix instead runs cargo test --features=<backend> for each of five backends on macOS and four on Ubuntu, which primarily exercises that each backend combination compiles and links cleanly on each platform rather than asserting behavior. Code style is enforced via clippy with warnings-as-errors and rustfmt, and the small surface area (one lib.rs, one build.rs) limits the risk that thin test coverage otherwise implies. Naming is consistent with the rest of the blas-lapack-rs family of crates, and the raw re-export convention is documented directly in the module-level doc comment.

What Makes It Unique blas-src doesn’t implement any linear algebra itself — its contribution is a well-established but non-novel pattern: unifying multiple mutually exclusive backend crates behind one feature-flag interface with a compile-time exclusivity check. What is distinctive is how central this small crate is to its ecosystem niche — it’s the de facto standard mechanism by which Rust scientific-computing crates avoid coupling themselves to a single BLAS vendor, letting the choice of accelerated (Accelerate, Intel MKL) versus portable (Netlib, OpenBLAS) linear algebra stay entirely with the application author.