OpenBLAS binary packages

[Artur Szostak]

I fear there is also a procedural and policy enforcement issue here. Clearly different people have implemented things in different ways, giving a non-standard and non-uniform look and feel to MacPorts ports. It makes for a poor user experience and the MacPorts community look bad.

After our 4 years of experience preparing RPM and MacPorts package repositories of our software we have seen that MacPorts packages take an order of magnitude more time to build and cause significantly more problems than RPMs. Mainly because there is a non-trivial probability that some port in the dependency tree will start breaking, and there is no way to pin or encode version ranges for the Portfile dependencies to prevent this.

________________________________________
From: macports-users <macports-users-bounces at lists.macports.org> on behalf of Chris Jones <jonesc at hep.phy.cam.ac.uk>
Sent: 15 May 2019 11:57
To: macports-users at lists.macports.org
Subject: Re: OpenBLAS binary packages

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
>