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
