Re: Advice on creating BLAS choice

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 05/02/18 02:02, Dr. Thomas Orgis wrote:
> Am Mon, 30 Apr 2018 10:33:37 -0500
> schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
>
> >   From a social engineering standpoint, I would choose BLAS_REFUSED, or
> > something else with a negative connotation, over BLAS_ACCEPTED.
> Agreed. Any hints on implementation? Particularily how per-package
> override should look? A packacke usually including
> mk/blas.buildlink3.mk, but having a custom pkgoption to use a specific
> BLAS instead?
>
> I guess we agree that all packages using the global BLAS choice
> mechanism really should all use the same BLAS. A local override should
> opt out of the global BLAS mechanism, instead of building that
> mechanism to read additional variables for blurring the configured
> choices. BLAS_REFUSED will just make the build fail early and make the
> admin think again about the global choice or use a package-specific
> option to make it use a special BLAS. Right?
>
>
> Alrighty then,
>
> Thomas
So either the admin or packager would have to specify a fallback option, 
or the system would have to support some sort of ranking system, e.g. in 
mk.conf:

BLAS_PREFERRED="openblas atlas netlib"

Then if openblas is refused for a given build, it will try atlas.  Could 
cause some library mixing issues with dependencies as you pointed out, 
but I don't think that's entirely avoidable in any system unless we 
force rebuilding all dependencies that use a different blas.  
Championship Rube Goldberg material...

We can't even guarantee that there exists a blas implementation that 
works with every dependent, although they all should.

So again I think the best approach is to keep it simple for the vast 
majority and trust that we can find solutions for the oddball cases.