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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
