no need for the '%s' % bit, just use self.mpi_option:

build_targets.append((self.mpi_option, 'test.parallel'))

Hmm, shouldn't we pass the full $CFLAGS here? If OpenMP is enabled via toolchainopts, it will include -fopenmp.

Amber doesn't quite use EB's CFLAGS at all, yet. So at the moment adding just the openmp flag is what should be done for consistency until that is dealt with.

Well, isn't this an opportunity to do so? What would be the correct way to let Amber honor the compiler flags put in place by EasyBuild? Wouldn't it be defining $CUSTOMBUILDFLAGS equal to $CFLAGS?

Fixing that requires more patching of makefiles that i haven't had time to dive into. The amber build is somewhat convoluted... There are places where CUSTOMBUILDFLAGS isn't used for instance.
Getting this right is not trivial.

os.getenv('LIBLAPACK', 'LIBLAPACK_NOT_SET') may make more sense

In theory, you could list OpenBLAS as a dependency and build with an MPI toolchain like gompi, which would make the current code crash hard because $LIBLAPACK is not defined.

Also, should we complain in an else that no LAPACK library was found?

Building without it is probably going to end in tears performance-wise?

Can't do "-lopenblas -lgfortran" (which LIBLAPACK is with foss) since the openblas could have been built by another compiler, like intel or pgi and in that case -lgfortran is wrong.
And doing a list of all the possible combos is just wrong.
But technically speaking, openblas does, or at least used to , not depend on fortran libs, so LIBLAPACK being -lopenblas -lgfortran is wrong i think. And one could then do just -lopenblas here.

So, at the moment, we really have to rely on LIBLAPACK giving us the correct set of libraries. (And that applies to all other easyblocks/easyconfigs really). But complaining if LIBLAPACK isn't set is a good thing to do.

@akesandgren Wait, os.getenv('LIBLAPACK') and os.environ['LIBLAPACK'] are both going to give you the value for $LIBLAPACK...

Or are you just pointing out an issue in case OpenBLAS is combined with non-GCC compilers?

If so, please open an issue in the framework repository to track that.

That's orthogonal to this though?

The issue is OpenBLAS built with non-GCC toolchains and probably that GCC-toolchain should define LIBLAPACK as just -lopenblas in this case, but i have too take a second look at how openblas is being built at the moment. It used to be the case that openblas was fortran-free. This might have changed with later versions and must be verified.

So orthogonal to the matter at hand yes.

If you'll check it immediately like this, this should be:

lapack = os.getenv('LIBLAPACK')
if lapack is None:
    raise ...
else:
    ...

@akesandgren This line is too long (> 120 chars). I would just drop the 2nd sentence, since a situation where OpenBLAS is there but $LIBLAPACK is not defined is quite strange...