Hey Bart, You're right on all counts. The name change wasn't strictly necessary but its an important change from a user perspective: when they load GCC they get a working compiler as they should reasonably expect.
The dependency in icc, ifort and other compilers is exactly to avoid the ambiguous scenario you describe where the same software and versions are available through different paths. The current setup allows us to strictly define the compiler family and put iccifort,PGI, GCC... in there. The other bonus (at least for me) is that with '--minimal-toolchains' I can now migrate things like CMake, git, autotools,... and especially vis libs like libX11 and wxwidgets to GCCcore and have them seamlessly available in all toolchains. This should save a lot of unnecessary struggle with such libs and other compilers. Alan On 17 Dec 2015 17:18, "Bart Oldeman" <[email protected]> wrote: > Hi, > > I am trying to get my head spun around those three modules. As far as > I can see the change has been as follows: > > GCC-4.9.3-binutils-2.25.eb => GCCcore-4.9.3.eb > GNU-4.9.3-2.25.eb => GCC-4.9.3-2.25.eb > icc-2015.3.187-GNU-4.9.3-2.25.eb => icc-2015.5.223-GCC-4.9.3-2.25.eb > > However apart from the name change I see two important differences: > 1. GCC-4.9.3-2.25.eb is marked moduleclass='compiler' and > easyblock='Bundle', but GNU-4.9.3-2.25 was marked > moduleclass='toolchain' and easyblock='Toolchain'. That lets > GCC-4.9.3-2.25 conflict with icc which is also marked 'compiler'. > 2. (most important I guess) icc/icc-2015.5.223-GCC-4.9.3-2.25.eb does > NOT depend on GCC/4.9.3-2.25 but instead directly on its > sub-components (GCCcore and binutils). This is unlike the older > icc*GNU* which depended on GNU. > > Now what I like about the new scheme: > * with the old scheme I can do > module load iccifort > > this loads > 1) icc/2015.3.187-GNU-4.9.3-2.25 4) GNU/4.9.3-2.25 > 2) GCC/4.9.3-binutils-2.25 5) ifort/2015.3.187-GNU-4.9.3-2.25 > 3) binutils/.2.25 6) iccifort/2015.3.187-GNU-4.9.3-2.25 > > however, then doing (in an hierarchical toolchain) a > "module load OpenMPI" is ambiguous since both the GNU and iccifort > variations now qualify. Just the order of MODULEPATH gets me in fact > the iccifort build of OpenMPI. > ===> with the new scheme GCC is replaced with GCCcore, and GNU is > gone, so only 5 modules loaded, and no ambiguity. > > Question: the same thing could have been done without the name change > (GCC->GCCcore, GNU->GCC) right? But I read the reason for not doing so > is a) clarity and b) having the possibility of different GCCcore and > GCC versions, e.g. GCCcore 4.9.3 + GCC 5.2.0-2.25? > > Regards, > Bart > > > -- > Dr. Bart E. Oldeman | [email protected] | > [email protected] > Scientific Computing Analyst / Analyste en calcul scientifique > McGill HPC Centre / Centre de Calcul Haute Performance de McGill | > http://www.hpc.mcgill.ca > Calcul Québec | http://www.calculquebec.ca > Compute/Calcul Canada | http://www.computecanada.ca > Tel/Tél: 514-396-8926 | Fax/Télécopieur: 514-396-8934 >
