All, I'm looking at ways to package lapack3 and atlas3.6 for cygwin, in support of an octave package eventually. These are numerical libraries; lapack3 is a fortran matrix arithmetic library package that is implemented in terms of calls to something called a blas (basic linear algebra system) library. It comes with a generic fortran blas implementation, which is expected to be replaced if possible by a tuned blas implementation optimized for the machine lapack runs on.
atlas is capable of providing that optimized implementation; however, it needs to be compiled from source on the machine in which it will run in order to be most effective. It would be possible to provide different binary packages for different processor architectures (Debian does this), however; this probably is a more complex project than I can handle at this point. Accordingly, I am considering building a combined lapack/atlas package, with a makefile switch that determines whether it is built with the generic blas package or whether it builds an optimized blas package from atlas source. The binary package would be built and distributed with the generic blas library; but instructions in the source package would be provided to facilitate build and installation of an optimized blas library. I guess the obvious question is why the packages need to be combined. The atlas library builds not only an optimized blas, but also optimized versions of some of the basic lapack routines. So if atlas is built, it needs to replace both lapack and blas libraries. There isn't a clean split between the libraries provided. See [1]. The libraries would be implemented as dll's, not as static libraries. I am soliciting comments and suggestions on the approach I have outlined here. At a minimum, I'd like to know whether the core maintainers would in principle be willing to approve a package built in this way, i.e. with a default binary configuration which could be replaced with an optimized configuration if the source package is installed. Thanks for your time, Jim Phillips [1]http://www.octave.org/mailing-lists/help-octave/2001/1332
