Update gsibec 1.4.2 -> 1.4.4

[eap]

No description provided.

[climbfuji]

More than a year ago, it was discussed that NOAA was going to test with MKL when using Intel/IntelLLVM instead of openblas, and then switch over to match the other partners (all others: Intel/IntelLLVM use MKL, GNU/LLVM native use OpenBLAS).

This still hasn't happened, hence the need to touch 14 files here.

The irony is that before we introduced spack-stack, NOAA was using hpc-stack and JCSDA was using jedi-stack, and both of them had Intel with MKL :-)

[rickgrubin-noaa]

More than a year ago, it was discussed that NOAA was going to test with MKL when using Intel/IntelLLVM instead of openblas, and then switch over to match the other partners (all others: Intel/IntelLLVM use MKL, GNU/LLVM native use OpenBLAS).

This still hasn't happened, hence the need to touch 14 files here.

The irony is that before we introduced spack-stack, NOAA was using hpc-stack and JCSDA was using jedi-stack, and both of them had Intel with MKL :-)

mkl isn't a variant in repos/spack_repo/builtin/packages/gsibec/package.py -- there is this check instead:

def cmake_args(self):
        return [
            self.define("ENABLE_MKL", self.spec.satisfies("^[virtuals=lapack] intel-oneapi-mkl"))
        ]

so it would be OK to remove +mkl and ~mkl from the config yamls and achieve the desired result, yes?

[climbfuji]

More than a year ago, it was discussed that NOAA was going to test with MKL when using Intel/IntelLLVM instead of openblas, and then switch over to match the other partners (all others: Intel/IntelLLVM use MKL, GNU/LLVM native use OpenBLAS).
This still hasn't happened, hence the need to touch 14 files here.
The irony is that before we introduced spack-stack, NOAA was using hpc-stack and JCSDA was using jedi-stack, and both of them had Intel with MKL :-)

mkl isn't a variant in repos/spack_repo/builtin/packages/gsibec/package.py -- there is this check instead:

def cmake_args(self):
        return [
            self.define("ENABLE_MKL", self.spec.satisfies("^[virtuals=lapack] intel-oneapi-mkl"))
        ]

so it would be OK to remove +mkl and ~mkl from the config yamls and achieve the desired result, yes?

Even better ;-) but what I said above is still valid in general for the environment and should probably be resolved.

[climbfuji]

I'll approve and merge after #2136 went in. Then I'll issue a follow-up PR to clean up the unnecessary ~mkl variants for gsibec, since the package doesn't have the variant.

[mathomp4]

Once all is happy, I can make a gsibec 1.5.0 pair-of-PRs