Can one of the admins verify this patch?

Automatic reply from Jenkins: Can I test this?

ok to test

@wpoely86: I'm a bit reluctant to merge this in, since the patch changes the behavior.
Having $MKLROOT set usually means you have an imkl module loaded. Simpy unsetting $MKLROOT might not be enough, since most the imkl stuff would still be available (e.g. $LD_LIBRARY_PATH and $CPATH would still be set). I have no idea how this would affect an ongoing imkl installation.
I've seen having $MKLROOT set make it break hard, but there may be other, more subtle problems...

What's your main motivation for this PR?

Well, it stopped my install (I had already an mkl installed elsewhere) and it annoyed me (no easy vs easy 😉 )

I thought EB unloaded any loaded modules before starting? That's a way nicer solution then giving a fatal error.

I also don't see the issue with mkl already in LD_LIBRARY_PATH or CPATH. That should not make any difference when installing imkl, only when building something with imkl but that won't be caught with this fatal error.

No, EB doesn't do a purge before starting (only when running unit tests). Some people may have modules loaded for a good reason (e.g. the cluster modules at HPC-UGent), so we can't do that.
I added in the fatal error because the issues that occurred when $MKLROOT was set were very strange, and it took me a while to figure out that the cause was having $MKLROOT defined...

So, I'm not convinced that stuff like $LD_LIBRARY_PATH and $CPATH would have no effect. Remember that for imkl we're building FFTW wrappers during the installation. We need to (try and) make sure the build also works when no other imkl is available in the session...

So, I feel strongly to not merge this in as is, because it's less strict. If someone has imkl available in their environment in some way, and the build fails because of it, it would be very non-obvious. If you had to unset $MKLROOT because EB was complaining about it, I would expect you put 1 and 2 together, and get a hint of what might be going wrong...

I don't want to just close this without you agreeing on this, this is not a dictatorship. ;-)

Well, in that case, I have no problem with closing this PR.

But I feel that a better solution then to check for ``$MKLROOTwould be to check forlibmkl_core.so` in the link path. That covers much more then just `$MKLROOT`.

@wpoely86: I won't close this just yet, I'll give it some more thought...

@wpoely86: After thinking about this a bit, I see no reason why not to make the change. I retested all existing imkl easyconfigs, all still work (I didn't expect otherwise :)), so good to go in. Thanks!