Allow Accelerate linkage, deny veclibfort & lapack

[zbeekman]

• Accelerate provides more than just BLAS and LAPACK functionality, see
  https://developer.apple.com/documentation/accelerate

• Veclibfort exists only to wrap Accelerate's BLAS/LAPACK

• LAPACK is a slow, seldom updated reference implementation

• Encourage usage of OpenBLAS

• Reverts PR audit: check Accelerate linkage for core formulae #6130

• Have you followed the guidelines in our Contributing document?

• Have you checked to ensure there aren't other open Pull Requests for the same change?

• Have you added an explanation of what your changes do and why you'd like us to include them?

• Have you written new tests for your changes? Here's an example.

• Have you successfully run brew style with your changes locally?

• Have you successfully run brew tests with your changes locally?

---

[zbeekman]

LMK if we want/need a unit test.

CC: @jonchang

Also, I'm really tempted to add -DBLA_VENDOR=OpenBLAS to std_cmake_args. There are some cases where formulae may want to remove this though, like if they depend on scalapack or similar. If the formula never calls find_package(BLAS) or find_package(LAPACK) (or they provide their own versions of these intrinsic CMake find modules) then a developer warning will be triggered, but which should be silenced because, IIRC, we pass -Wno-dev.

[zbeekman]

Could also set BLAS_ROOT and LAPACK_ROOT in the environment to point to OpenBLAS.

[jonchang]

I didn’t know that Accelerate did all of that, so agree with the PR in principle. Though, are there separate dylibs for BLAS vs other functionality? On mobile so can’t check. If so we could narrow it to only warn links against Accelerate’s BLAS while permitting other uses.

My concern with setting the default BLAS vendor in std_cmake_args is that formula authors wont know to edit that if they want to use a different BLAS implementation. Perhaps an audit if eg someone depends on veclibfort on a cmake build?

[zbeekman]

This PR triggers audit failures whenever depends_on “veclibfort” || depends_on “lapack” for all formula.

I agree with your concerns about -DBLA_VENDOR=..., probably a bad idea, but it would be nice to try to force uniformity. ¯\_(ツ)_/¯

I can see if it’s possible to detect if packages are using Accelerate specifically for BLAS/LAPACK

[zbeekman]

Does anyone know how to find out which dylibs within a framework are linked against?

@jonchang @MikeMcQuaid I can see within the Accelerate Framework there are BLAS and LAPACK specific dylibs, but I'm not sure how to figure out what a dylib (e.g. from veclibfort) links to within a Framework. Any ideas?

[jonchang]

Does brew linkage provide this information? I recall seeing specific libBLAS links but can’t confirm right now.

[zbeekman]

No, if something links w/ accelerate it just shows the framework.

EDIT

$ brew linkage --verbose veclibfort
System libraries:
  /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
  /usr/lib/libSystem.B.dylib

[MikeMcQuaid]

Makes sense to me, thanks. A much simpler approach seems better and we can always dig into individual errors where need be.

[MikeMcQuaid]

I don’t think we should change the general CMake behaviour. Otherwise 👍🏻

[MikeMcQuaid]

Thanks both!