Fix Windows builds: handle scipy-openblas64 ILP64 interface and MSVC incompatibilities

[Copilot]

Windows builds failed due to scipy-openblas64's ILP64 interface using different symbol names (scipy_dgetrf64_ vs dgetrf_) and MSVC rejecting C99 complex types in its headers.

Changes

pyproject.toml - Windows cibuildwheel config:

• Set EASYSBA_LAPACK_LIBS = "libscipy_openblas64_" (exact filename including lib prefix required by MSVC)
• Removed INCLUDE environment variable (avoids scipy-openblas64 headers with C99 complex types)
• Kept LIB path for linker

src/lapack_compat.h - Platform-specific symbol naming:

// Windows uses ILP64 with scipy_ prefix and 64_ suffix
#if defined(_WIN32) || defined(_WIN64)
#define FORTRAN_WRAPPER(name) scipy_##name##64_
#else
#define FORTRAN_WRAPPER(name) name##_
#endif

void FORTRAN_WRAPPER(dgetrf)(...);  // scipy_dgetrf64_ on Windows, dgetrf_ elsewhere

Context

• ILP64: 64-bit integer interface used by scipy-openblas64 on Windows
• LP64: Standard 32-bit integer interface used on Linux/macOS
• Symbol names differ between interfaces; preprocessor adapts at compile time
• Project's own headers avoid MSVC C99 compatibility issues

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

Updates Windows wheel builds to link against scipy-openblas64 (ILP64) and avoid MSVC incompatibilities by adjusting symbol naming and cibuildwheel environment configuration.

Changes:

• Switch Windows build deps and repair step to scipy-openblas64 + delvewheel, and set EASYSBA_LAPACK_LIBS to the MSVC-required import lib name.
• Introduce a FORTRAN_WRAPPER() macro to map LAPACK symbols to scipy_*64_ on Windows.
• Add a CodeQL source root marker file.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/lapack_compat.h	Adds Windows-specific LAPACK symbol name mangling for ILP64 scipy-openblas64.
pyproject.toml	Updates cibuildwheel Windows env to link against scipy-openblas64 and bundles DLLs via delvewheel.
.github/workflows/cibuildwheel.yml	Installs Windows-only host dependencies needed for cibuildwheel path resolution.
_codeql_detected_source_root	Adds a detected source root marker (likely CodeQL-generated).

Comments suppressed due to low confidence (1)

_codeql_detected_source_root:1

• This looks like a generated CodeQL artifact rather than a source file the project should version-control. If it’s produced by CI tooling, it should typically be removed from the repo and added to .gitignore to avoid churn and accidental inclusion in releases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

scipy-openblas64 is an ILP64 interface on Windows, which implies LAPACK integer arguments are 64-bit. Keeping lapack_int as int (32-bit on Windows/MSVC) will mismatch the expected ABI for symbols like scipy_dgetrf64_ and can lead to stack/argument corruption. Consider conditionally defining lapack_int as a 64-bit type (e.g., int64_t) when targeting the *64_ symbols, and include the appropriate header for that type.

[Copilot]

The symbol mangling is currently keyed only on Windows (_WIN32/_WIN64), which hard-codes a single LAPACK ABI choice for all Windows builds. If the project ever links against a different LAPACK/OpenBLAS distribution on Windows (LP64 naming like dgetrf_), this will force incorrect symbol names. Consider gating the scipy_##name##64_ mapping behind an explicit build macro (e.g., EASYSBA_USE_SCIPY_OPENBLAS64 / EASYSBA_LAPACK_ILP64) so consumers can opt in/out without editing headers.

Suggested change

	// On Windows with scipy-openblas64, symbols have scipy_ prefix and 64_ suffix
	#if defined(_WIN32) || defined(_WIN64)
	#define FORTRAN_WRAPPER(name) scipy_##name##64_
	#else
	#define FORTRAN_WRAPPER(name) name##_
	// On Windows with scipy-openblas64, symbols have scipy_ prefix and 64_ suffix.
	// Enable this mangling only when explicitly requested via build macros.
	#if defined(_WIN32) || defined(_WIN64)
	#if defined(EASYSBA_USE_SCIPY_OPENBLAS64) || defined(EASYSBA_LAPACK_ILP64)
	#define FORTRAN_WRAPPER(name) scipy_##name##64_
	#else
	#define FORTRAN_WRAPPER(name) name##_
	#endif
	#else
	#define FORTRAN_WRAPPER(name) name##_

[Copilot]

The inline python -c one-liner has nested quoting and positional sys.argv usage, which is easy to break when edited and hard to troubleshoot in CI logs. A more maintainable approach is to move this logic into a small repository script (or a dedicated module entry point) and invoke that from repair-wheel-command, keeping the TOML simple and reducing quoting/escaping risk.