OpenBLAS binary packages
aszostak at partner.eso.org
Wed May 15 09:01:45 UTC 2019
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.
From: Joshua Root <jmr at macports.org>
Sent: 15 May 2019 10:38:13
To: Artur Szostak
Cc: MacPorts Users
Subject: Re: OpenBLAS binary packages
> I am trying to understand why I am not able to get the OpenBLAS port to install exclusively from binary packages, i.e. using something like:
> sudo port -b install OpenBLAS
> Even if I prepare a local repository with the prebuilt binary packages it indicates that it is not able to find any binary package and the above command fails. I have no such problem with other ports.
> I had a quick look to see if there is something in the Portfile itself that forces compilation from source but did not find anything obvious. Is there such a mechanism? what is it? and can this be disabled / overridden?
The Portfile does disable the use of binary archives, by clearing the
The assumption seems to be that if you are using OpenBLAS, then you must
require maximum performance and hence a build that is tuned for your
specific hardware. A pre-built binary of course cannot provide this.
There is no way to change this short of editing the Portfile or setting
your own archive_sites value on the command line.
More information about the macports-users