Ilhan Polat

> However, there are no obvious other places for it right now That's circling the argument. If a array library needs it, they can implement it in their native code....

Yes exactly, so then `kron` has to go into the standard if solve_are or solve_lyapunov should support the standard. Or it has to fall back to NumPy arrays. We discussed...

I am dealing with the same issue for the Fortran translations. This feels like it should be somehow simpler; the LAPACK and BLAS API has been frozen since decades and...

ABI stability should be present since this is a pure C interface without anything mangled. Or my very-little-left brain remembers it so. But like you said build and linking is...

By the way I'm attempting to use ```c #include ``` at the top of the file and not our definitions. Because our `show_config()` says it should be there ``` Build...

True. I think I am getting confused by trying out five different things at the same time to fix a single problem. In general, when I don't compile my own...

What I typically do on Windows I build OpenBLAS then use `$env:PKG_CONFIG_PATH="C:\opt\lib\64\pkgconfig\"` for meson to discover it and build scipy with it. `dev.py` used to copy the `dll` to the...

I must confess though, I am really surfing in waters that I'm not allowed to. So maybe it is just pointless ranting I can't decide now. But it would be...

This is still a pain for BLAS which is not Fortran anymore in any libraries we support (except the reference BLAS but we can leave it aside for this discussion)....

> Now we have `extern void symbolname(int);` waiting for us for the C linker to see. It will call a Fortran subroutine `foo`. Like I said, BLAS is not fortran...