[SciPy-dev] adding LAPACK and BLAS to the source code

eric jones eric at enthought.com
Mon Jun 24 13:41:11 CDT 2002

> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Prabhu Ramachandran
> Sent: Monday, June 24, 2002 1:15 PM
> To: scipy-dev at scipy.net
> Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
> >>>>> "EJ" == eric jones <eric at enthought.com> writes:
>     EJ> We just had the unpleasant experience of getting SciPy to
>     EJ> build on the Sun architecture.  In the end, it didn't prove
>     EJ> that hard -- it was all the mis-steps that were painful.  Most
>     EJ> of SciPy builds without a hitch -- it is only the LAPACK and
>     EJ> BLAS stuff that causes major problems.
> Right now my biggest trouble with scipy is that it needs a recent
> version of Atlas.  The version that Debian ships with is too old for
> scipy.  Some of my older code does not work with scipy anymore because
> my build is broken.  I already need to download too many packages from
> source.  While I understand that a newer version of atlas has features
> that are worth it, sometimes folks dont use the features.  By making
> it mandatory to install atlas it becomes hard to use scipy.  Packaging
> lapack might eliminate these problems but by sticking lapack into
> scipy's CVS tree aren't we making the scipy cvs tree that much bigger?

It does grow -- I see this as the major drawback.

> Sticking it in CVS also means that even if the package is removed it
> still lingers in the attic (which can be painful sometimes).  

I haven't dealt with this, but (perhaps naively) feel this isn't that
huge of an issue.  If there is evidence to the contrary, please
elaborate.  I guess the other deal is that I don't think we'll take it
out in the future, accept when a new version of LAPACK comes out.

> Also,
> aren't there any other issues with including lapack in scipy?  Aren't
> we in some sense forking lapack or is lapack no longer under
> development??

We're not really forking since I doubt we make any modifications -- its
purely a logistical issue.  We already have code from FFTPACK, ODEPACK,
FITPACK, cephes, amos, etc. in SciPy.  We have made a few modifications
in these to get them working on newer compilers, etc., but nothing to
major.  There kept there just to make building SciPy easier.  LAPACK
would be included for the same reason.  


More information about the Scipy-dev mailing list