Try weaning ourselves completely off of staticfloat/julia* Homebrew taps

[staticfloat]

This is a shot at fixing #30949. Note that this will cause us to start building SuiteSparse again, but that's not that bad; SS builds pretty quickly. The most important two are LLVM and OpenBLAS, which are both covered by BB at this point, so we don't need to use my outdated tap anymore.

[ViralBShah]

We also have a SuiteSparseBuilder. Time to move to using it:
https://github.com/JuliaLinearAlgebra/SuiteSparseBuilder

And also openlibmbuilder?
https://github.com/JuliaMath/OpenlibmBuilder

[vtjnash]

ld: library not found for -lopenblas
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [/Users/travis/build/JuliaLang/julia/usr/manifest/suitesparse] Error 1

[staticfloat]

Yeah, it's a problem with the SuiteSparse build step. I'm taking Viral's suggestion and getting BB-built SuiteSparse ready for primetime.

[staticfloat]

@andreasnoack @ViralBShah As part of integrating BB-installed SuiteSparse I have attempted to reduce differences between the BB installation script and this one. The two big ones are:

• We don't use make library but instead do for subproj in <list of sub projects>; do make -C ${subproj} library; done. This avoids trying to build things like GraphBLAS that we don't care about.
• I have set -DNPARTITION once again. That wasn't set when building SS 4.4.6, but I'm not sure if that was on purpose or not; it seems to me that without setting -DNPARTITION we would require libmetis?

Please let me know if I've done anything wrong that will screw up the sparse landscape.

[ViralBShah]

-DNPARTITION is right. I don't think we ever distributed Metis. However, given that Metis is now apache licensed, and we have BB, it would be nice to have going forward.

Seems like this is updating suitesparse - which is good. I don't expect there are any breaking API changes.

For list of subprojects, it seems we are doing the following:
for proj in AMD BTF CAMD CCOLAMD COLAMD CHOLMOD LDL KLU UMFPACK RBio SPQR

I believe we do not have bindings for KLU, LDL or RBio. @andreasnoack Do you know if we can safely ignore those and not build them?

[staticfloat]

Do we want to disable OpenMP? We do so on Windows in BB-land, and the OpenMP flag is causing a problem on the FreeBSD CI bot (where I assume OpenMP is just not installed; it is installed on BB). I remember back in the mists of time we disabled OpenMP because we wanted a different way of controlling parallelism, but I'm not sure if that is purposeful or not.

Unless I hear otherwise, I am going to disable OpenMP in the from-source builds here just so that we can get CI passing again. Note that while we have BB tarballs available for all platforms, we're only really using it on Travis OSX and Appveyor, presumably because we want to continue testing building from source on some of the platforms.

[staticfloat]

Okay, shortlist of changes within this branch:

• Bump SuiteSparse version to 5.4.0, change installation parameters somewhat (add -DNPARTITION and disable -fopenmp when building from-source)
• Add BB installation for SuiteSparse and OpenLibm, turn on both for OSX Travis, turn on only SuiteSparse for Appveyor, since it seems there's some special OpenLibm handling there, not sure what to do about it.

If this passes CI and the build changes are acceptable to the Sparsity Shifu's, let's merge it.

[staticfloat]

Looks like this is good to go; the 32-bit windows build timed out, but I'm trying it again.

[StefanKarpinski]

🎉