I just returned to this list -- what is the "new infrastructure" we are
"preparing for"?
BTW, I am also on the Atlas mailing list. There was quite a bit of
activity over the weekend regarding GCC 4. It seems the default Fortran
in GCC 4 is Fortran 95, which has instilled great trepidation in some of
the "old-timers" on the Atlas list. In any event, should I wish to
experiment with GCC 4, how do I go about doing so without creaming my
system? Do I need a whole new machine/partition?
The good news is that Gentoo is *way* better than Debian or Fedora in
its behavior re Atlas. Atlas is *designed* to tune itself to your
machine, and the Debian packages, for example, are *way* out of date and
compiled seperately for each architecture. I don't think I'll ever pry
Dirk Eddelbuettel away from Debian, but there's a lot of hope for the
rest of the scientific computing community, at least those who want a
working Atlas out of the box. :)
Other notes: R. Clint Whaley, the head of the Atlas project, mentioned
that he was interested in making shared libraries of Atlas. I told him
that the Gentoo package already did that for BLAS-Atlas and LAPACK-Atlas. :)
Could we get a "testing/unstable" Atlas in Portage? Right now, they are
at 3.7.10, and I only see a 3.7.10 for blas-atlas, not for atlas itself
or lapack-atlas. I think the x86-64 users will want 3.7.10 across the
board, and might also want to be able to compile selected code with GCC 4.
Peter Bienstman wrote:
Hi,
I've been looking through the tree to see which packages use lapack/blas, and
which of them are prepared for the new infrastructure. There are actually far
less packages than I anticipated:
Still depends on old infrastructure:
sys-cluster/hpl
Already uses virtual/blas or virtual/lapack in unstable branch:
dev-lang/R
sci-geosciences/grass
sci-misc/camfr
sci-chemistry/mpqc
sci-mathematics/octave
sci-misc/xfoil
Uses own code, but could benefit from transition:
dev-python/numeric (see http://bugs.gentoo.org/show_bug.cgi?id=81520)
Peter
--
[EMAIL PROTECTED] mailing list
