Package name
esmf
Package version/tag
9.0.0bXX
Build options
Same as before
Installation timeframe
spack-stack v2.2 or v2.3 depending on testing
Other information
I worked with @theurich to get the macOS + LLVM Flang build for ESMF working (see esmf-org/esmf#558). This update is now in ESMF 9.0.0b17.
Currently, spack-stack is on b11, I think? So there are probably other updates that come with this. And to this end, I might ask @theurich to chime in.
For example, I know I'll probably need to update the esmf/package.py because of esmf-org/esmf#557 (which added nagclang which is not yet a valid ESMF_COMPILER in the spack package). Of course, this doesn't go to mainline spack until 9.0.0 is official.
But there are also things like esmf-org/esmf#567 which I think moved ESMF_COMPILER=intel to now default to the LLVM compilers instead of the classic ones. I think spack should be fine here. And @theurich did some YAML like fixes in esmf-org/esmf#574 that hopefully should take care of any issues with #2027
However, the biggest update/change might be esmf-org/esmf#549 . That was brought about by @AlexanderRichert-NOAA in spack/spack-packages#5045 . This adds the new ESMFConfig.cmake and ESMFConfigVersion.cmake files on install.
Now, spack should do its thing right there. That's fine. But, it's our user code that might need testing. GPT helped with some thoughts I have for GEOS at GEOS-ESM/ESMA_cmake#561 and some PRs off that.
NOTE: Even with b17, I still might need help from ESMF (aka a patch on our end). I made an issue (esmf-org/esmf#579) and PR (esmf-org/esmf#580) for some weirdness I saw with NAG.
Package name
esmf
Package version/tag
9.0.0bXX
Build options
Same as before
Installation timeframe
spack-stack v2.2 or v2.3 depending on testing
Other information
I worked with @theurich to get the macOS + LLVM Flang build for ESMF working (see esmf-org/esmf#558). This update is now in ESMF 9.0.0b17.
Currently, spack-stack is on b11, I think? So there are probably other updates that come with this. And to this end, I might ask @theurich to chime in.
For example, I know I'll probably need to update the
esmf/package.pybecause of esmf-org/esmf#557 (which addednagclangwhich is not yet a validESMF_COMPILERin the spack package). Of course, this doesn't go to mainline spack until 9.0.0 is official.But there are also things like esmf-org/esmf#567 which I think moved
ESMF_COMPILER=intelto now default to the LLVM compilers instead of the classic ones. I think spack should be fine here. And @theurich did some YAML like fixes in esmf-org/esmf#574 that hopefully should take care of any issues with #2027However, the biggest update/change might be esmf-org/esmf#549 . That was brought about by @AlexanderRichert-NOAA in spack/spack-packages#5045 . This adds the new
ESMFConfig.cmakeandESMFConfigVersion.cmakefiles on install.Now, spack should do its thing right there. That's fine. But, it's our user code that might need testing. GPT helped with some thoughts I have for GEOS at GEOS-ESM/ESMA_cmake#561 and some PRs off that.
NOTE: Even with b17, I still might need help from ESMF (aka a patch on our end). I made an issue (esmf-org/esmf#579) and PR (esmf-org/esmf#580) for some weirdness I saw with NAG.