OpenBLAS binary packages

Chris Jones jonesc at hep.phy.cam.ac.uk
Wed May 15 09:57:59 UTC 2019


Hi,

On 15/05/2019 10:47 am, Joshua Root wrote:
> 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.

I was going to suggest exactly the same, as its what I have done in a 
few other places where builds can potentially benefit from 'native' 
builds, i.e. use ` -march=native` or similar in the build.

Because of this I have generally called these variants 'native'. See for 
instance py-tensorflow. Because this is a non-default variant, the user 
has to actively use it, I never bothered with clearing archive_sites as 
the build bots never build non-default variants. But perhaps it is still 
a good idea to add it as well ;)

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

Indeed. and the best ways to achieve this are, in order of preference

1. submit a github PR implementing it, for review.
2. submit a trac ticket requesting the change (with or without a patch, 
although with will likely speed up the process).

cheers Chris

> 
> - Josh
> 


More information about the macports-users mailing list