Do not define CMake variables from environment (CMAKE_C_COMPILER=$CC)

[Flamefire]

The CMakeMake EB does set a couple of CMake Cache vars:

easybuild-easyblocks/easybuild/easyblocks/generic/cmakemake.py

Line 104 in a97990b

env_to_options = {

This is not required as all but really ancient versions (<2.7) of CMake do this automatically. This was only recently documented but has been "always" the case. So setting -DCMAKE_C_COMPILER="$CC" is not required.

In addition to simplifying the EB code this also avoids warnings: On projects using only C++ CMake will spit out warnings:

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_C_COMPILER
    CMAKE_C_FLAGS
    CMAKE_Fortran_COMPILER
    CMAKE_Fortran_FLAGS

Caveat: CMake will only use the environment variables on the first call, aka no CMakeCache exists. But as EB cleans the build folder first this is given.

In favor for a warning-free build I'd suggest to remove that code.

[boegel]

W.r.t. the caveat: EasyBuild doesn't exactly clean the build folder, it starts from a freshly unpacked source tarball.
So, what if the CMakeCache.txt is included in the source tarball?

I understand your motivation, but I feat this may do more harm than good.
Is there a way to tell CMake not to print the warning for variables that are not used (not sure if that's a good idea either though...)?

[Flamefire]

So, what if the CMakeCache.txt is included in the source tarball?

Highly unlikely. In this case compilers and features etc. will be in conflict

W.r.t. the caveat: EasyBuild doesn't exactly clean the build folder, it starts from a freshly unpacked source tarball.

Really? Well, maybe it should by default create a temporary, non-existing build folder. Some CMake projects don't even work when called "in-source"

[boegel]

So, what if the CMakeCache.txt is included in the source tarball?

Highly unlikely. In this case compilers and features etc. will be in conflict

We're talking scientific software here, I've learned never to use the term "highly unlikely" in that context. ;)

W.r.t. the caveat: EasyBuild doesn't exactly clean the build folder, it starts from a freshly unpacked source tarball.

Really? Well, maybe it should by default create a temporary, non-existing build folder. Some CMake projects don't even work when called "in-source"

We've been considering that for a while, but haven't until now, see #616.

[Flamefire]

We're talking scientific software here, I've learned never to use the term "highly unlikely" in that context. ;)

Ok, then play it safe: In CMakeMake.configure_step check for existance of CMakeCache.txt and error out if it exists. IF (big "IF"!) anything breaks, one can either use the separate_build_dir and/or implement a work-around in the EC/EB and file a bug report. This will ensure that if it builds, it will be correct.

We've been considering that for a while, but haven't until now, see #616.

Oh, great! I like that change.