WRF: Add version 3.9.1.1 and improve recipe robustness#19882
WRF: Add version 3.9.1.1 and improve recipe robustness#19882adamjstewart merged 5 commits intospack:developfrom numericalalgorithmsgroup:robust_wrf
Conversation
adamjstewart
left a comment
adamjstewart
left a comment
There was a problem hiding this comment.
@MichaelLaufer can you review this?
* Include version 3.9.1.1 as common benchmarking workload * Fix compilation against recent glibc (detect spack installed libtirpc) * Detect and handle failed compilation (upstream use make -i)
fix build jobs fix maintainers fix pkgconfig dependency use Executable to run compile stage repair some overzealous autoformatting by black
|
All changes included and I also cleaned up some of the more egregious formatting choices my autoformatter made... Apologies for the force push - I tried to rebase my local repo onto the latest develop and got in a complete mess. |
adamjstewart
left a comment
adamjstewart
left a comment
There was a problem hiding this comment.
Few more comments on the Spack recipe. I don't know much about WRF so I can't review the patches.
adamjstewart
left a comment
adamjstewart
left a comment
There was a problem hiding this comment.
Looks good to me from my end. Since this is a pretty big change I'm still hoping for a review from @MichaelLaufer or another WRF user. Let's give it a few days. If we don't hear back, ping me and I'll merge.
Thanks! Do you want this squashed to a single commit before merge? |
Nah, we automatically squash and merge all PRs, so there's no need to do it yourself. |
@ptooley @adamjstewart |
|
In that case I'll merge for now and we can backport any changes if they are needed later. Thanks for reviewing @MichaelLaufer! |
3 participants
PR to improve several aspects of WRF support in Spack:
The headline issue here is the fact that upstream use
make -i -kand their custom make script always returns 0. This means that the standard approach of checking the return code won't detect a failed build. Instead we need to actually check the output of the script to see if it succeeded. My approach is the least-bad solution I could find.Second big issue is that the configure script enforces interactivity and dynamically generates its option. Previous recipe version had response values hardcoded for an assumed x86 platform. This new version should be platform independent and has been tested on at least aarch64 and x86_64.
Additionally I have added support for v 3.9 which is a common HPC benchmarking workload, and fixed an issue with failure to compile against recent glibcs that don't ship sunrpc headers.