OpenBLAS binary packages

[Joshua Root]

On 2019-5-15 19:01 , Artur Szostak wrote:
> OK, I must be blind. Thanks for indicating archive_sites. I completely missed that when looking at the Portfile yesterday. This explains everything.
> 
> This raises the question: how is the MacPorts team mitigating the cost of compiling OpenBLAS over and over again when trying to prepare production binary packages for other ports where OpenBLAS happens to be in the dependency tree?
> Here at ESO we have gone to great effort to build our software as MacPorts packages, where each package is built in a pristine clean environment (using VMware virtualisation on a MacPro). Now we see that a large fraction of the time is being spent building OpenBLAS, rather than our software, which is a 3rd party dependency in our case.

I would guess we're not mitigating that cost, which as you point out is
not a good thing.

My preferred solution for ports of this kind would be to build a generic
binary for minimum spec hardware when no variants are requested, and
have a consistently-named variant that clears archive_sites and turns on
tuning, instruction set usage etc. specific to the user's machine. The
gmp port is another that could use this treatment, and no doubt there
are a few more.

Of course this plan "just" needs someone to do the work to implement it.

- Josh