Sean Farley sean at
Wed Oct 1 10:30:21 PDT 2014

vincent writes:

>> Yes, atlas has a bunch of compiler variants. I would love for most or all of them to go away. But part of atlas needs fortran so it needs to deal with that at least. And I believe Vince argued that for atlas and other performance-critical scientific software it is beneficial to be able to try different compilers to get the absolute best performance. I'm not sure who actually has time to do that however. Also, atlas already builds itself multiple times with different compiler options to get best performance, which is why building atlas takes so long.
> This is mainly historical now. Clang has gone a long way from what it was two years ago and can now outperform GCC on most kernels. But modern clang versions are not available on all platforms (10.5 PPC). Besides, fortran is still required for Atlas as long as you decide to build the  BLAS/LAPACK interface, which almost all other ports depend on. The idea of keeping multiple gcc variants was to avoid  the installation of a fresh copy of GCC in case the version the user had installed and the one Atlas required weren't the same, knowing that the version number is nowhere near to be important as long as the fortran compiler is available (it's just to build the API).

The development burden of all these gcc versions is pretty high now. I
would suggest a (perhaps controversial) simpler approach:

- Always build BLAS/LAPACK for ATLAS (testing for its existence in a
  dependent port is burdensome)

- Always use clang for C/C++

- Drop PPC support

> I just wish llvm had a fortran front-end to avoid this mess. And, needless to say, I'll welcome any suggestion to improve the layout of the port.

Ain't that the truth.

More information about the macports-dev mailing list