Use generic blas for building

[isuruf]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[hmaarrfk]

What other blas is there?

[ngam]

What other blas is there?

maybe for this... conda-forge/numpy-feedstock#253 (comment)

The idea is to enable this: https://conda-forge.org/docs/maintainer/knowledge_base.html#switching-blas-implementation

[h-vetinari]

What other blas is there?

maybe for this... conda-forge/numpy-feedstock#253 (comment)

Not maybe, definitely. ;-)

Building against our reference-lapack allows switching out the blas/lapack implementation at environment creation time (as described in the link you posted), and ideally, all feedstocks depending on blas/lapack should be built this way.

[ngam]

@isuruf should we try generic (lowercase) here?

https://github.com/pytorch/pytorch/blob/789070986c32835bd03f2d14bd77dd31e59ef95d/cmake/Modules/FindBLAS.cmake#L292-L309

[ngam]

OTOH https://github.com/pytorch/pytorch/blob/789070986c32835bd03f2d14bd77dd31e59ef95d/cmake/Dependencies.cmake#L226

So I have no idea...

[ngam]

I think BLAS is being picked up correctly, but it is complaining about BLAS_LIBRARIES

[ngam]

Let's add

        - libcblas              # [not x86]
        - liblapack             # [not x86]

to build for the cross-compile case. I think that's what's missing, so let's try it?

[ngam]

testing in #168