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

Prabhu Ramachandran prabhu at aero.iitm.ernet.in
Mon Jun 24 22:28:40 CDT 2002

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

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

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

If you choose to backup your entire CVS tree you'll also end up
backing up all of the files in the attic.  This can be painful.

    >> 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??

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

Sure, but its one more thing to keep track of.  If you really dont
think its too big a deal I guess it makes sense to just go ahead and
add lapack as well.  Maybe you could put all these extra packages into
a separate cvs module so that only folks who want it can check it out?
This way the extras are separated from the main scipy code.  Just a


More information about the Scipy-dev mailing list