Put ATLAS archdef tarballs into patches/ARCHS and resync ATLAS-lib dir

[jpflori]

Not sure why but it seems the tarballs we shipped did not make the git transition. The ATLAS-lib dir is also outdated. Please use the tarball at:

• ​http://boxen.math.washington.edu/home/jpflori/upstream/atlas-3.10.1.20140128.tar.bz2

[jpflori]

Ive take the opportunity to add an ARM archdef tarball as provided at ​http://math-atlas.sourceforge.net/errata.html#armhardfp

---

New commits:

​0553986

Reintroduce ATLAS archdefs tarballs.

[jpflori]

The ATLAS-lib issue is surely my bad as it is already wrong in the sage 5.13 tarball... This make ATLAS not so useful on Cygwin, whence the severity change.

[vbraun]

Since we have to make our own ATLAS tarball anyways to embed lapack, I would be in favor of putting the archdef tarballs in there as well. Even though they are small, they are still binary stuff that we should keep out of the repo if possible.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​1154b0d

Update ATLAS checksum.

[jpflori]

Replying to vbraun:

Since we have to make our own ATLAS tarball anyways to embed lapack, I would be in favor of putting the archdef tarballs in there as well. Even though they are small, they are still binary stuff that we should keep out of the repo if possible.

Yes, we also have to generate the autotools project an d put it in. I'm not so found of not tracking and putting the archdefs tarballs into the ATLAS tarball as there is no easy way to generate them as for the autotools project, or getting them somewhere upstream as for the lapack tarball.

[vbraun]

Putting them into our git repo doesn't make it easier to obtain the archdefs either, it jut puts binary crap into our repo. If anything, it makes it worse for non-Sage users to get the archdefs.

[jpflori]

Ok, so let's just put them somewhere on sagemath...

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

[jpflori]

Ok, now the archef tarballs are within the "upstream" tarball. I've taken the opportunity to add a Solaris archdef tarball. I've slightly reworked the atlas related scripts. Please review.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​e56945e

Reintroduce ATLAS archdef tarballs.

[jpflori]

I've put the current archdefs at ​http://boxen.math.washington.edu/home/jpflori/archdefs/

[jpflori]

This fails to build on Cygwin64 when SAGE_FAT_BINARY is set, and is easy to fix: just don't force isa extensions as the win64 abi is not the same as the amd64 one and asm code cannot be assembled...

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3772086

Disable ATLAS ISA extensions on Cygwin64.

[vbraun]

Changing the tarball without the version (excluding the patchlevel) is not supported ATM, I think. We cache files in the upstream/ dir as package-versionwithoutpatchlevel.tar.gz, so this ticket would break builds for everybody who has the old tarball cached.

Either combine with an upstream version bump or wait until the build system can handle this case.

Apart from that, positive review ;-)

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​f4f17d6

Change package version to properly take tarball changes into account.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d8da989

Merge remote-tracking branch 'trac/develop' into ticket/15615