On 29/10/14 16:50, Backeljauw Franky wrote:
Op 29-okt.-2014, om 15:58 heeft Ward Poelmans <ward.poelm...@ugent.be> het
volgende geschreven:
In that case, then what’s the benefit of having multiple CMake modules, e.g.
CMake-3.0.0-intel-2014b, CMake-3.0.0-foss-2014b, CMake-3.0.0-GCC-4.8.3? I would
think that, depending on the version you load, CMake would also know it has to
take the compiler with which it was built…
There is no benefit of having multiple CMake with different
toolchains. We already discussed multiple times what to do with
toolchain independent modules (stuff like autotools, cmake, bison,
...) and haven't come up with the perfect solution. They way EB
currently works, we need to build CMake for each toolchain. What
CMake-3.0.0-intel-2014b means is: CMake 3.0 build with intel 2014b
toolchain, not CMake 3.0 which always uses intel 2014b toolchain to
build stuff.
I understand — it’s an EB “issue” we have to live with. No problem.
Just to know: is that subject to change anywhere in the future (e.g., starting
from EB version 2 or so)?
There a couple of things we can do here:
* make toolchain modules define $CC, $CXX, etc. (optionally); something
like this is being supported in the Intel MPI easyblock for example
(cfr. https://github.com/hpcugent/easybuild-easyblocks/pull/493)
* make EasyBuild also consider subtoolchains when resolving dependencies
(e.g. also consider a CMake built with a GCC toolchain when resolving
dependencies for a goolf build); this will not fix the runtime CMake
behavior, but it will avoid the need for a CMake module per toolchain
(or at least make that significantly easier)
We don't have to wait for this until EasyBuild v2, since we can disable
these features by default and provide switches to turn it on.
However, someone needs to step up and actually look into this...
If easy build takes care of this, then what does it do ‘extra’?
It sets a bunch of environmental variables and gives some arguments to
CMake where to look for includes, libraries, etc. Run easybuild with
the -l option, and you will see what it does (or just look into the
cmakemake class).
As long as we are sure that this happens, it’s fine for us, so we will check
those to see what happens exactly… Thanks for the pointer.
If you want CMake to do something in particular, specify it hard, e.g.
using -DCMAKE_C_COMPILER and friends (see
https://github.com/hpcugent/easybuild-easyblocks/blob/master/easybuild/easyblocks/generic/cmakemake.py#L87).
There's a similar issue for the MPI wrappers commands, e.g. the mpicc
provided by Intel MPI which defaults to using GCC (!).
Adding support for making these wrappers behave more sensibly is the
point of https://github.com/hpcugent/easybuild-easyblocks/pull/493.
K.
The fastest way to build something with the intel toolchain using a
CMake build system is: CC=icc CXX=icpc cmake .
I guess once we find out what happens exactly we’ll be making something similar
available to our users.
— Regards,
Franky
