[SciPy-dev] adding LAPACK and BLAS to the source code
Prabhu Ramachandran
prabhu at aero.iitm.ernet.in
Mon Jun 24 23:28:40 EDT 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
thought.
cheers,
prabhu
More information about the SciPy-Dev
mailing list