Takeshi Enomoto <take...@macports.org> writes:
> Dear David,
>> I just noticed that you created a port lapack (including BLAS) in r146856.
>> Is this really useful? We already have the ATLAS port which provides BLAS
>> and LAPACK; the OpenBLAS port which provides exactly the same implementation
>> of LAPACK from netlib as your port lapack; and the built-in Accelerate
>> Framework and the vecLibFort port providing a Fortran interface for it. All
>> of these are optimized and therefore should be faster than the
>> straightforward netlib implementation, and use directly of
>> Accelerate/vecLibFort is of course by far the fastest to install. So, what
>> is the use of a separate port lapack? I suspect its main effect will be to
>> have users or port packagers use this one instead of an optimized
>> implementation because they do not realize the optimized ones exist. For
>> example, see the recent r153943. I would suggest removing it.
> I started LAPACK port to provide man pages after Apple removed them.
> Some email exchanges with the LAPACK developers I became aware of the
> * LAPACK from netlib is active.
So many things I could say but I will refrain.
> * the man pages can be generated from LAPACK source by make man.
> * the most of the performance gain is due to BLAS, which can be obtained from
> * CBLAS and LAPACKE can be provided.
> I believe that there is nothing to be harmful to leave the port.
Yeah, that's fine with me. I see there's a linear_algebra portgroup
which should abstract away all these ports, correct (perhaps with some
macports-dev mailing list