On Wed, 8 Jul 2015 at 11:58 -0000, Jack Perdue wrote:
> We (EB) really need to come up with a more timely manner of
> declaring toolchains.
>
> It's interesting... while reading this morning's mail (probably
> while the telecon was going on across the pond), I noticed a
> notification from Intel for a new MPI release.
It is always tempting to wait 'just a little bit' for that just
released or soon to be released change, but that often leads to even
more 'just a bit longer' (I do this far too often myself).
For our users who want to chase version numbers, I leave that to them
as something they can build privately.
> The immediate question that arose was "oh shit, now WTF do I call a
> toolchain with this change?".
>
> To which, there is no clear answer.
I think the answer it to not worry the details and not over think
toolchains. I don't really want to chase toolchain components but
instead want a tested and fairly stable toolchain. Preferably with
just one or two updates a year (versus the CentOS 6 toolchain which is
several years old).
I'm looking forward to foss-2015b whether it has GCC 5.1, 5.2 or even
4.X. Based strictly on version numbers (without any insight as to
significant differences), I would suggest GCC 5.1 as something stable.
I could probably live with foss-2015a which seems to work well and
wait until the November hack-a-thon for foss-2015b.
> Note: intel-2015b, if I decide to use it, will likely be 2015B with
> GCC 4.9.2 or 4.9.3.
You might try naming your site specific toolchains tamu-intel-2015X so
as to more visibly indicate they are site specific.
> Of course, with Intel's new MPI this morning, I need something new.
Do you actually really need to instantly upgrade to the latest intel
compiler? There might be some practical reasons (especially if Intel
does not leave older versions around).
> I just wish y'all had all the answers for me before I had the
> question. :)
They do have a good number of answers to questions I'm glad I don't
even need to think about asking.
I'm mostly an easybuild freeloader. I thank the easybuild developers
who do monitor the toolchain and other software changes and do a lot
of testing and validation of the easyconfig files. This saves me a
lot of work determining which toolchain components to use.
Stuart
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone
