Nightly homebrew check

[zbeekman]

Test PRs into develop and nightly test of develop built using the Homebrew formula.

Nightly tests of develop built on macOS using Homebrew's build "formula" for OpenBLAS. This emulates the Homebrew binary build and distribution process so you will know if changes in Homebrew adversely impact OpenBLAS, and if changes in OpenBLAS will impede a quick release in Homebrew before minting a new release.

[isuruf]

Is this using gcc or clang?

[zbeekman]

@isuruf

Is this using gcc or clang?

This is using whatever the instructions in the latest Homebrew formula are for openblas and building the develop branch only. Actually, come to think of it, this is not actually checking PRs and I should remove the PR condition. This will only check develop.

Currently/historically this was using the latest stable GCC and will continue to do so until Homebrew/homebrew-core#50252 is merged into homebrew-core, at which point it will switch to native apple clang (unless the maintainers thing there is a good reason to stay with GCC, at which point we'll apply the patch you committed fixing the aarch64 issue or wait for the next release of OpenBLAS).

This nightly testing is effectively a light-weight emulation of our binary build process in Homebrew prior to releasing a new version of a package.

[zbeekman]

Once these workflows finish running on my fork, and I can see that they didn't have any issues I'll remove the draft status of this PR and mark ready for review.

[isuruf]

If that's the case, then issues like #2421 will not be uncovered right?

[martin-frbg]

If that's the case, then issues like #2421 will not be uncovered right?

Guess I'll just refrain from causing such issues in the future if I can , one kind of useful nightly build is certainly much better than none. (And the original issue behind what caused #2421 was ultimately related to iOS compilation, which I think this PR does not address anyway)

[isuruf]

one kind of useful nightly build is certainly much better than none

Definitely. I think if both gcc and clang builds can be added, that'll be more useful.

[zbeekman]

@martin-frbg

If that's the case, then issues like #2421 will not be uncovered right?

I am not sure I understand what you're asking.

This PR is designed to test develop, so that when a new release is tagged (based on develop, right?) there won't be any surprises when homebrew maintainers go to upgrade OpenBLAS to the latest release. This is what I was doing when I discovered #2421. So my entire purpose in opening this is to help you guys see when something on your end would break distributing the next release of OpenBLAS with Homebrew. Likewise, if a package OpenBLAS depends on i.e., gfortran (part of gcc in homebrew) or libomp does something to break OpenBLAS, or someone modifies the formula and causes breakage then you guys can report it to us over at Homebrew/homebrew-core. (And feel free to tag me.)

@isuruf

I think if both gcc and clang builds can be added, that'll be more useful.

As I explained above, my primary goal was to detect when there might be an otherwise undetected interaction between changes in OpenBLAS with Homebrew packaging and distribution of OpenBLAS, or upstream dependency or Homebrew issues breaking OpenBLAS.

Nevertheless, if you really want me to, I can add an additional nightly test that builds OpenBLAS' develop branch using the other C/C++ compiler and Homebrew's formula. This may end up being fragile, and a wacky thing to do, because we don't officially support compilation with a compiler that's different than the one specified in the formula.

So, assuming we decide to merge Homebrew/homebrew-core#50252 as is and switch to using Apple Clang, then the tests I added as they currently stand will automatically switch to using what Homebrew uses. If you really want me to, I can add testing that is similar to this, but builds OpenBLAS with either the latest stable GCC---assuming the OpenBLAS upgrade PR goes through in its current state---or Apple Clang if it is decided that Homebrew wants to keep building OpenBLAS with GCC for some reason. i.e., what is here now tests the way homebrew builds OpenBLAS and I'll add a build using homebrew with whatever the other C compiler would be. Note that all Fortran is built with gfortran.

Let's wait and see what happens with Homebrew/homebrew-core#50252. If it goes through in its current state and you would like me to add macOS testing of OpenBLAS built with the latest GCC using the homebrew "formula" then I will add it at that time.

[zbeekman]

The action running on my branch looks good: https://github.com/zbeekman/OpenBLAS/actions/runs/40818440

I'll mark this as ready for review to remove the draft status. Once it's running, I can submit a PR to add a status badge, if that's of interest.

[martin-frbg]

@zbeekman I was just quoting isuruf's comment , that was not a question from me.
FYI releases currently get tagged on the 0.3.0 branch (after merging changes from develop), not on develop itself. This oddity came about as xianyi put me in control of the release process, back then a 0.3.0 branch was created for this purpose (also resulting in master gathering dust).

[zbeekman]

PPC test failure on Travis-CI, but it must have been present before since I did not touch any code.

[martin-frbg]

Yep, that is a pre-existing bug uncovered by a new test merged earlier today. #2427 will take care of it.

[martin-frbg]

Appveyor seems to be sleeping but would not be affected by this commit anyway, so merging now.

[martin-frbg]

Unfortunately the homebrew check is now failing with "Error: your xcode(11.3.1) is outdated" and I have no idea how to fix this as xcode itself is not mentioned anywhere in the script @zbeekman ?

[martin-frbg]

Tried to address this in 4412ee1 by setting the DEVELOPER_DIR variable to the latest version (11.4) that is installed rather than the default 11.3.1, so hopefully fixed for now (but will probably happen again)