> 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.
* 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.
The message from the upstream developer on 15 March 2016.
> Dear Takeshi,
> I am ccing Julien Langou - he is one of the PI of LAPACK and our most active
> I saw your vecLibFort port - this is awesome and it was dearly needed.
> > vecLibFort is lightweight but flexible shim designed to rectify the
> > incompatibilities between the Accelerate/vecLib BLAS and LAPACK libraries
> > shipped with Mac OS X and FORTRAN code compiled with modern compilers such
> > as GNU Fortran.
> First, there is no real complete “optimized LAPACK” library around that I
> know if except the one's from vendors (for Example: MKL INTEL)
> Second, most of the performance from a LAPACK code will come from an
> Optimized BLAS library (i.e. Veclib)
> Veclib is based on Atlas, and I did not check, but I believe the LAPACK
> included inside VecLib and vecLibFort correspond to the ATLAS LAPACK - which
> is a small subset of LAPACK library.
> So I think to write a port for LAPACK itself is a great idea.
> Also LAPACK now includes LAPACKE - A C Standard Interface to LAPACK - A lot
> of users are using it.
macports-dev mailing list