[SciPy-user] scipy 0.7.0.dev4373 + atlas FAILED (failures=2, errors=12)

[Xavier Gnata]

Well from my point of view, it is much harder compile scipy than to 
compile gcc or a kernel because it looks like black magic :(

To be very pragmatic, I do agree on this  statement :

"it would be good to have less documentation, as an 'anti-incentive'."

but if you want the svn versions to be tested you need also a doc for "experts" users.

I do like to try to fix a bug in a numerical algo but first I would like to be able to install the svn scipy version and to run the scipy.test() without errors coming from the installation itself.

"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone".

Of course it is not that esay because scipy is based on a mix of C/fortran old (but nice) libs...

Cheers,
Xavier

> Johann Cohen-Tanugi wrote:
>   
>> well, I am not sure the doc marathon will deal with building scipy, at 
>> least as a priority....
>>     
>
> Yes, I agree. I think too many people try to build all the dependencies 
> by themselves, and are surprised it is difficult. Frankly, I almost 
> think it would be good to have less documentation, as an 
> 'anti-incentive'. Building software which rely on binaries linked with 
> several languages is just something inherently difficult and requires a 
> lot of knowledge for the platform. The fact that ATLAS, BLAS and LAPACK 
> use non standard build procedures certainly does not help either.
>
>   
>>  This is going to remain a very tough issue 
>> because scipy depends on packages that are complex and hard to build. 
>> Note that if you dont need smart lin. algebra you still have plenty of 
>> good stuff in scipy despite this lapack failure. Maybe what would be 
>> nice is for the scipy build process to clearly disable some specific 
>> libs if something goes wrong and report it at the end of the build.
>>     
>
> That's one of the reason I worked on numscons: in numscons, all 
> dependencies are actually checked, contrary to numpy.distutils which 
> just checks for the *presence* of a dependency. For example, if your 
> atlas is somewhat buggy and cannot be linked, numscons detects it 
> because before using atlas, it tries to build/run a small program which 
> uses atlas, and this is logged.
>
> cheers,
>
> David
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-user
>