Jameson Nash

are you trying to use MinGW compilers (gcc version = 4.8) should work (although they are incompatible with the binaries produced by older versions of gcc)

you can trace the logic from here to see what constitutes a good cc: https://github.com/vtjnash/atlas-3.10.0/blob/5b4899fc806c367552c052d6d2cf3febb1e8fea0/CONFIG/src/probe_comp.c#L1988 you might also try setting verbose > 1 and see what the utility gives you...

the nocygwin flag is poorly named. it means for a cygwin environment, cross-compile for mingw. This flag is not valid for a native mingw compile. For reference, I tested with...

yeah, i didn't document that very well for this fork (the whole cygwin / mingw-on-cygwin / msys-mingw / etc thing is really confusing to me also). the whole purpose of...

Sure, that’s well in line with what this package already does, and just needs to be added to the syntax rules.

Why don't you want this for emscripten? That's not a meaningful or useful goal. This can be implemented provide an appropriate return value, and is easy since it's just returning...

looks like you've removed the requirement for this? it also would be nice to hook up BinDeps support, esp. since both portaudio and libsndfile are already available via WinRPM

That is almost entirely due to OpenBLAS, to run on threads. We commit about 285 MB, then OpenBLAS commits about 915 MB. It goes away if you set `OPENBLAS_NUM_THREADS=1`.

The threads used to be somewhat lazily allocated, but that was removed in https://github.com/JuliaLang/julia/pull/42442, and that logic has not been restored, despite several PRs that attempted to do so, but...

n.b. that OpenBLAS memory usage scales fast as the product of the maximum number of threads configured and the current number of threads visible at startup, which was temporarily increased...