Hi Brett,
On 02/09/15 18:35, Bode, Brett wrote:
Thanks Kenneth (and others).
My situation is exactly what you mentioned below (CentOS 6 on haswell). I
actually had started down the path of building on top of the GNU toolchain, but
wasn’t sure that was the best path since I then had to change most other builds
to use that (or try…) instead of GCC. Hacking the GCC module to include
binutils seemed simpler than changing other stuff to use GNU though I don’t
disagree that is probably the right way to do it.
Combining --robot and --try-toolchain will take you a long way here...
I am also curious if there is a description describing the direction you are
heading with the toolchain naming convention. Isn’t the foss just a rename of
the goolf toolchain?
We introduced the 'foss' and 'intel' toolchains with the intention to
promote them as 'common' toolchains (I really need to get this
documented :-)).
The idea is that if multiple sites use (either or both) of these, we can
all benefit even more from each others work (especially if we take steps
towards being more independent of the OS (version), like we did with
including binutils).
Initially, the 'intel' toolchain was identical to 'ictce', other than
the name/version. At some point, we included our own GCC in it,
underneath the Intel compilers, to be independent of the OS-provided GCC
(which is required for recent C++ features, for example). We the last
iteration (2015b), also binutils was included. This doesn't mean the
'ictce' toolchain will no longer be supported, but it should be
considered as less 'robust' since more aspects are left to the mercy of
the OS.
For 'foss', the story is similar now we've added binutils in 2015b,
which discriminates the goolf versions up until now from foss.
We also picked a 'neutral' toolchain name ('free & open source
software') other than a mnemonic derived from the name of the toolchain
components (*G*CC, *O*penMPI, *O*penBLAS, *L*APACK, *F*FTW), to have the
freedom to switch future versions of the foss toolchain away from e.g.,
OpenMPI (to MVAPICH, or ...) or OpenBLAS if there's a good reason to do
so, without inducing a name change.
The idea is to refresh the composition of (the versions of) the common
toolchains (components) every 6 month, to stay on top of things, which
is also reflected in the <year>(a|b) version format.
regards,
Kenneth
